（譯注：這篇文章主要還是針對于非專業人員及個人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 進行更新更新、或者網站出現問題、需要服務或技術支援時，還是應該将将其交由專業人士處理。這樣會節省你的時間和減少頭痛，并讓你可以将精力集中你的公司業務而非網站上。