維護開源備份工具：見解等

備份策略似乎是一個已解決的問題，但係統管理員經常遇到如何正確備份資料、將資料儲存在何處以及如何跨不同軟體環境標準化備份過程的問題。 2011 年，我們開發了自訂備份腳本，可以有效處理客戶 Web 專案的備份。這些腳本多年來為我們提供了良好的服務，根據需要將備份儲存在我們的儲存和外部儲存庫中。然而，隨著我們的軟體生態系統的發展和多樣化，我們的腳本出現了不足，缺乏對 Redis 和 MySQL/PostgreSQL 等新技術的支援。腳本也變得很麻煩，除了電子郵件警報之外沒有任何監控系統。

我們曾經緊湊的腳本演變成一個複雜且難以管理的系統。為不同的客戶更新這些腳本變得具有挑戰性，特別是當他們使用自訂版本時。到去年初，我們意識到我們需要一個更現代的解決方案。

在這篇文章中，我們將解釋我們在開發nxs-backup時遇到的所有困難，並分享我們的經驗和挑戰。您還可以在您的專案中測試該工具並分享您的經驗，我們非常有興趣聽取您的意見。現在，讓我們開始吧！

我們列出了新系統的要求：

• 最常用軟體的備份資料：（檔案：離散與增量；MySQL；PostgreSQL；MongoDB；Redis）；
• 將備份儲存在熱門的儲存庫中：（FTP；SSH；SMB；NFS；WebDAV；S3）；
• 在備份過程中出現問題時接收警報；
• 擁有統一的設定文件，集中管理備份；
• 透過連接外部模組新增對新軟體的支援；
• 指定收集轉儲的額外選項；
• 能夠使用標準工具恢復備份；
• 易於初始配置。 所有這些要求都是根據我們大約 5 年前的需求列出的。不幸的是，並非所有人都被釋放。

我們研究了在創建第一個版本的 nxs-backup 之前就已經存在的開源解決方案。但他們都有自己的缺陷。例如，Bacula 對我們來說過載了不必要的功能，由於大量的手動工作（例如，用於編寫/搜尋資料庫備份的腳本），初始配置是相當費力的工作，並且恢復副本需要使用特殊的實用程序等等

毫不奇怪，我們在考慮重寫我們的工具時遇到了同樣的問題。四年內發生一些變化並且在線出現新工具的可能性並不高，但仍然如此。

我們研究了一些以前沒有考慮過的新工具。但是，正如前面所討論的，這些也不適合我們。因為他們沒有完全滿足我們的要求。

我們最後得到兩個重要結論：

1. 現有的解決方案都不完全適合我們；
2. 看來我們已經有足夠的經驗和瘋狂來第一次編寫我們的解決方案了。我們基本上可以再做一次。 這就是我們所做的。

在探索新版本之前，讓我們先看看我們之前有什麼以及為什麼它對我們來說還不夠。

舊版支援MySQL、PostgreSQL、Redis、MongoDB等資料庫，檔案離散增量複製，多種遠端儲存（S3；SMB；NFS；FTP；SSH；WebDAV），並具有備份輪替、記錄等功能、電子郵件通知和外部模組。

現在，更多關於我們關心的事情。

在任何 Linux 上運行二進位檔案而無需重新啟動原始檔

隨著時間的推移，我們使用的系統清單已經大大增加。現在我們服務的專案使用非標準 deb 和 rpm 相容發行版，例如 Arch、Suse、Alt 等。

最近的系統在運行 nxs-backup 時遇到困難，因為我們只收集了 deb 和 rpm 軟體包，並且支援的系統版本列表有限。我們在某個地方重新提取了整個包，在某個地方只是二進位文件，在某個地方我們只需要運行原始程式碼。

由於需要使用原始程式碼，使用舊版對於工程師來說非常不方便。更不用說這種模式下的安裝和更新需要更多時間。您不必每小時設定 10 台伺服器，而只需在一台伺服器上花費一小時。

我們很早就知道，如果您擁有一個沒有系統依賴項的二進位文件，可以在任何發行版上運行，並且不會遇到不同版本的庫和系統架構差異的問題，那麼情況會好得多。我們希望這個工具是一樣的。

使用 nxs-backup 最小化 docker 映像並在設定檔中支援 ENV

最近，很多專案都在容器化環境中運作。這些項目也需要備份，我們在容器中執行 nxs-backup。對於容器化環境，最小化圖像大小並能夠使用環境變數非常重要。

舊版沒有提供使用環境變數的機會。主要問題是密碼必須直接儲存在配置中。因此，您必須將整個配置放入變數中，而不是一組僅包含密碼的變數。編輯大型環境變數需要工程師更加集中精力，並且使故障排除變得更加困難。

此外，在使用舊版本時，我們必須使用已經很大的 Debian 映像，其中我們需要添加多個程式庫和應用程式才能正確備份。

即使使用圖像的精簡版本，我們也得到了約 250Mb 的最小大小，這對於一個小型實用程式來說是相當大的。在某些情況下，這會影響收集的啟動過程，因為影像被拉到節點上的時間較長。我們想要獲得不大於 50 MB 的圖像。

無需保險絲即可使用遠端儲存

容器環境的另一個問題是使用fuse掛載遠端儲存。

當您在主機上執行備份時，這仍然是可以接受的：您已經安裝了正確的軟體包並在核心中啟用了熔斷器，現在它可以工作了。

當你需要在容器中放置保險絲時，事情就會變得有趣。如果不升級直接存取主機系統核心的權限，問題就沒有解決，而且安全等級明顯下降。

這需要協調，並不是所有客戶都同意削弱安全策略。這就是為什麼我們不得不制定大量我們甚至不想回憶的解決方法。此外，附加層增加了故障機率，並且需要對已安裝資源的狀態進行額外監視。直接使用他們的 API 來使用遠端儲存會更安全、更穩定。

監控狀態並不僅向電子郵件發送通知

如今，團隊在日常工作中使用電子郵件的情況越來越少。這是可以理解的，因為在群組聊天或群組通話中討論問題要快得多。 Telegram、Slack、Mattermost、MS Teams 和其他類似產品廣泛傳播。

我們還有一個機器人，它會發送各種警報並通知我們。當然，我們希望看到像 Telegram 這樣的工作空間中的備份崩潰的報告，而不是電子郵件以及數百封其他電子郵件。順便說一句，一些客戶還希望在其 Slack 或其他通訊工具中查看有關故障的資訊。

此外，您很希望能夠即時追蹤狀態並查看工作的詳細資訊。為此，您需要更改應用程式的格式，將其變成惡魔。

效能不足

另一個急性疼痛是在某些情況下表現不足。

其中一個客戶端有一個幾乎 1 TB 的巨大文件轉儲，並且所有這些文件都是小文件 - 文字、圖片等。我們正在收集這些內容的增量副本，並遇到以下問題 - 每年的副本需要三天。是的，好吧，舊版本無法在不到一天的時間內消化掉這一卷。

鑑於目前的情況，我們實際上無法恢復特定日期的數據，這是我們根本不喜歡的。

最初，我們使用 Python 實作了備份解決方案，因為它簡單且靈活。然而，隨著需求的成長，基於 Python 的解決方案變得不夠用了。經過充分討論，我們決定用 Go 重寫系統，原因如下：

1. 編譯與依賴：Go 的 AOT 編譯器產生通用的、無依賴的二進位文件，簡化了跨不同系統的部署；
2. 效能：Go 固有的多執行緒能力保證了更好的效能；
3. 團隊專業知識：我們擁有 Go 經驗豐富的開發人員，而不是 Python 經驗豐富的開發人員。

尋找解決方案

所有上述問題都或多或少地給IT部門帶來了相當明顯的痛苦，導致他們將寶貴的時間花在固然重要的事情上，但這些成本本來是可以避免的。此外，在某些情況下，會為企業主帶來一定的風險──某一天沒有數據的機率雖然極低，但並非為零。我們拒絕接受現狀。

Nxs-備份3.0

我們的工作成果是 nxs-backup v 3.0 的新版本，最近更新到了 v3.8.0
新版本的主要特點：

• 實作所有儲存設施和所有類型備份的相應介面。作業和儲存在開始時初始化，而不是在工作運行時初始化；
• 透過 API 使用遠端儲存。為此，我們使用各種庫；
• 在配置中使用環境變量，這要歸功於我們在專案中使用的 go-nxs-appctx 迷你應用程式框架；
• 透過鉤子發送日誌事件。您可以配置不同的等級並僅接收所需等級的錯誤或事件；
• 不僅指定備份的時間段，也指定特定的備份次數；
• 備份現在只需在從 2.6 核心開始的 Linux 上運行即可。這使得使用非標準系統變得更加容易，而且建置 Docker 映像的速度也更快。鏡像本身減少至 23 MB（包含額外的 MySQL 和 SQL 用戶端）；
• 能夠以 Prometheus 相容的格式收集、匯出和保存不同的指標。
• 限製本機磁碟速率和遠端儲存的資源消耗。

我們嘗試保留大部分配置和應用程式邏輯，但存在一些更改。都與上一版本缺陷的最佳化和修正有關。

例如，我們將遠端儲存庫的連接參數放入基本配置中，這樣我們就不會每次為不同類型的備份指定它們。

以下是備份基本配置的範例。它包含通知通道、遠端儲存、日誌記錄和作業清單等常規設定。這是郵件通知的基本主要配置，我們強烈建議使用電子郵件通知作為預設方法。如果您需要更多功能，可以查看文件中的參考。

server_name: wp-server
project_name: My Best Project

loglevel: info

notifications:
  mail:
    enabled: true
    smtp_server: smtp.gmail.com
    smtp_port: 465
    smtp_user: j.doe@gmail.com
    smtp_password: some5Tr0n9P@s5worD
    recipients:
      - j.doe@gmail.com
      - a.smith@mail.io
  webhooks: []
storage_connects: []
jobs: []
include_jobs_configs: [ "conf.d/*.conf" ]

關於陷阱的幾句話

我們預期會面臨某些挑戰。否則的話就是愚蠢的。但有兩個問題造成了最強烈的傷害。

記憶體洩漏或非最佳演算法

即使在先前版本的 nxs-backup 中，我們也使用自己的檔案歸檔實作。此解決方案的邏輯是盡量避免使用外部工具來建立備份，而使用檔案是最簡單的步驟。

在實踐中，該解決方案被證明是可行的，儘管從測試中可以看出，對於大量文件來說並不是特別有效。當時我們把它寫成 Python 的細節，並希望當我們切換到 Go 時看到顯著的差異。

當我們最終進行新版本的負載測試時，我們得到了令人失望的結果。效能沒有任何提升，記憶體消耗甚至比以前更高。我們正在尋找解決方案。閱讀了很多關於這個主題的文章和研究，但他們都說使用「filepath.Walk」和「filepath.WalkDir」是最好的選擇。這些方法的效能只會隨著語言新版本的發布而提高。

為了優化記憶體消耗，我們甚至在建立增量副本時犯了錯誤。順便說一句，損壞的選項實際上更有效。由於顯而易見的原因，我們沒有使用它們。

最終，一切都取決於要處理的文件數量。我們測試了1000萬。垃圾收集器似乎無法清除這麼多產生的變數。

最終，意識到我們可能會在這裡浪費太多時間，我們決定放棄我們的實現，轉而採用經過時間考驗且真正有效的解決方案 - GNU tar。

當我們想出更有效的解決方案來處理數千萬個檔案時，我們可能會回到自我實現的想法。

如此不同的ftp

使用 ftp 時出現了另一個問題。事實證明，不同的伺服器對於相同的請求表現不同。

對於同一個請求，你要么得到正常的答案，要么得到與你的請求無關的錯誤，或者在你期望的時候沒有得到錯誤，這是一個非常嚴重的問題.

因此，我們不得不放棄使用庫“prasad83/goftp”，轉而使用更簡單的“jlaffaye/ftp”，因為第一個庫無法與 Selectel 伺服器正常工作。錯誤是在連接時，第一個嘗試獲取工作目錄中的文件列表，並得到了上級目錄訪問權限的錯誤。使用“jlaffaye/ftp”就不存在這樣的問題，因為它更簡單，並且不會向伺服器發送任何請求。

下一個問題是沒有請求時斷開連線。並非所有伺服器都這樣做，但有些伺服器確實如此。所以我們必須在每次請求之前檢查連接器是否脫落並重新連接。

最重要的是從伺服器取得檔案的問題，或者說清楚，嘗試取得不存在的檔案。有些伺服器在嘗試存取此類檔案時會出錯，其他伺服器會傳回一個甚至可以讀取的有效 io.Reader 介面對象，只有你得到一個空位元組。

所有這些情況都是憑經驗發現的，必須自己處理。

結論

最重要的是，我們修復了舊版本的問題，影響工程師工作並為業務帶來一定風險的事情。

我們還有上個版本中未實現的“願望”，例如：

• 備份加密；
• 使用 nxs-backup 工具從備份還原；
• 用於管理作業清單及其設定的 Web 介面。

此列表現已新增清單：

• 自己的作業排程程式。使用自訂設定代替系統克隆；
• 新的備份類型（Clickhouse、Elastic、lvm 等）。

當然，我們很樂意了解社群的意見。您還看到哪些其他發展機會？您會新增哪些選項？

您可以在其網站上閱讀文檔並了解有關 nxs-backup 的更多信息，如果您想留下任何問題，我們的網站上還有故障排除部分。

我們已經在 Telegram 頻道中對即將推出的功能進行了民意調查。關注我們，參與此類活動，為工具的發展做出貢獻！

下次再見！

以上是維護開源備份工具：見解等的詳細內容。更多資訊請關注PHP中文網其他相關文章！