（譯註：這篇文章主要還是針對於非專業人員及個人Drupal站長，對於專業的 Drupal 團隊和公司而言 Drupal 的升級更新都有規範的操作流程，完全是家常便飯，不可能出現文中出現的這些情況。儘管如此，裏面也還是有一些內容值得大家瞭解。）
有時我希望Drupal的升級和維護能夠像Wordpress那樣簡單就好了，輕輕一點，Wordpress就能夠在不影響其運行的情況下完成自身以及所有插件的更新。Drupal則完全不一樣，稍有不慎你就會把你的網站搞癱。
Drupal 之所以這麼難搞是因爲它的很多模塊都需要依賴於其它模塊纔可以正常運行，這正是它得以模塊化、靈活以及便於集成的優點，但這同時也是一件壞事，因爲你必須對所有這些關係有所瞭解，才能在升級出現問題時進行排查。
許多 Drupal 站點的管理者，並不瞭解蘊藏在 Drupal 表面之下的事物是怎樣結合和運作的。所以當他們看到“你有可用的安全更新”時，便覺得有必要試試進行更新——“嘿，我可以更新Windows，更新一下Drupal能有多難？”——如果你不是Drupal工程師、建站人員或者任何瞭解站點構造的人，建議你還是尋求專業人事的幫助和支持。
使用Drupal內置更新功能進行更新?
使用Drupal內置的更新機制進行更新是我們所知道的最常見錯誤。儘管表面上它看起來即簡單又好用，但問題是如果一旦出錯，你便無法回頭了——Drupal崩潰後你便不再能夠進入網站進行操作，即使有備份，也不能通過 Backup & Migrate 模塊進行恢復。
導致Drupal崩潰或失敗的常見原因有以下一些：
下載內核或模塊更新出錯
網絡連接斷開中斷更新進程
更新版本與其它模塊不兼容
更新版本與服務器上其它組件不兼容，如當前使用PHP版本
FTP出錯
文件系統出錯（如權限出錯）
很多用戶都是線上的網站直接進行操作，這樣做最壞的情況是網站出錯而不能用了，你的用戶和客戶會因此流失。如果網站下線時間過長，也可以同 Google 和百度說拜拜了。
使用FTP對Drupal進行更新?
如果你比較精明，使用 FTP 對 Drupal 進行更新或升級，相對而言會安全很多，但也不是絕對安全。如果你對Drupal的目錄結構不夠了解，則很可能將文件上傳到錯誤的目錄、覆蓋錯誤的文件，或者漏掉 .htaccess 這樣的隱藏文件。
曾經有一次，一個客戶將同一個模塊上傳到3個不同的目錄並疑惑網站爲什麼運行得那麼慢。他並不知道，Drupal嘗試3次加載那個模塊並導致內存泄漏。所以最好知道東西應該放在哪裏，否則很可能會出問題。
使用FTP進行更新的另一個問題是，你依然是將更新模塊上傳到你的線上站點，不論是模塊或PHP不兼容，都可能導致出錯而讓站點下線。除非你重新恢復之前的文件或者找到問題的解決辦法。（譯註：如果升級之後還運行了數據庫更新，恢復文件可能也不能解決問題）
應該怎樣正確地進行升級？
首先，永遠永遠永遠不要在線上站點直接進行內核或模塊升級，永遠不要。專業的Drupal團隊會使用模擬服務器（或稱開發服務器、測試服務器）對你的網站更新進行測試和調試，從而確認是否所有的更新都是無害且不會導致網站損壞。這樣，可以在不影響線上網站正常運行的情況下對問題、錯誤進行處理和修復，儘量保證用戶、客戶、Google和百度不會因爲網站升級出錯而離你而去了。
同時，使用 Git 對所有更新進行版本控制，以便確保當升級出現問題時，可以更方便地查找問題和進行恢復。
一旦所有更新都確認OK，便可以放心的將它們上傳到線上服務器。更新時使用 Rsync 或 Git，儘量不要使用FTP，前者會更快速、更智能。
寫在最後
當Drupal更新發布後，應該至少在一個月內進行更新，如果更新涉及安全問題，則更新週期還應該更短。（譯註：如果是安全更新，應該儘快進行。如果非安全更新，不必操之過急）
雖然很可能平時 Drupal 網站的日常維護都是由你們自己負責，但需要對 Drupal 進行升級更新、或者網站出現問題、需要服務或技術支持時，還是應該將將其交由專業人士處理。這樣會節省你的時間和減少頭痛，並讓你可以將精力集中你的公司業務而非網站上。
原文地址：http://drupalct.org/drupal-update/why-you-should-not-update-drupal-yourself.html