備份系統很多，但如果服務的伺服器分散在不同的地理、不同的客戶端，需要湊合使用作業系統怎麼辦？
美好的一天， 哈布爾!
我叫娜塔莉亞。 我是 NPO Krista 應用程式管理員小組的組長。 我們是我們公司專案組的營運人員。 我們的情況相當獨特：我們在公司的伺服器和位於客戶站點的伺服器上安裝和維護我們的軟體。 在這種情況下，無需備份整個伺服器。 只有「基本資料」才是重要的：DBMS 和各個檔案系統目錄。 當然，客戶有（或沒有）自己的備份規定，並且通常會提供某種外部儲存來儲存備份。 在這種情況下，建立備份後，我們確保發送到外部儲存。
有一段時間，出於備份目的，我們湊合使用了 bash 腳本，但隨著配置選項的增加，該腳本的複雜性也成比例增長，在某一時刻，我們需要「將其徹底銷毀，然後… 」。
現成的解決方案由於多種原因並不適合：由於需要分散備份、需要在客戶端本地儲存備份、設定的複雜性、導入替換、存取限制。
對我們來說，編寫我們自己的東西似乎更容易。 同時，我想要得到一些足以滿足我們未來 N 年情況的東西，但有可能擴大範圍。
任務條件如下：
- 基本備份實例是自治的並在本地運行
- 備份和日誌的儲存始終位於客戶端網路內
- 實例由模組組成 - 一種“建構函式”
- 需要與目前的 Linux 發行版相容，包括過時的發行版，潛在的跨平台是可取的
- 要使用實例，透過 ssh 存取就足夠了；無需打開其他連接埠
- 最大程度地方便設定和操作
- 可以（但不是必須）有一個單獨的實例，讓您可以集中查看來自不同伺服器的備份的狀態
您可以在這裡看到我們的想法：
軟體是用python3寫的； 適用於 Debian、Ubuntu、CentOS、AstraLinux 1.6。
該文件發佈在儲存庫的 docs 目錄中。
系統運作的基本概念：
action – 實作一個原子操作（資料庫備份、目錄備份、從目錄 A 傳送到目錄 B 等）的操作。 現有的操作位於 core/actions 目錄中
任務 – 任務，描述一個邏輯「備份任務」的一組操作
時間表 – 時間表，一組有可選的任務執行時間指示的任務
備份配置儲存在yaml檔案中； 通用配置結構：
- 通用設置
- actions 部分：該伺服器上使用的操作的描述
- 計劃部分：所有任務（操作集）的描述以及由 cron 啟動的計劃（如果需要這樣的啟動）
應用程式目前可以執行的操作：
- 支援我們的主要操作：透過pg_dump備份PostgreSQL，透過tar備份檔案系統目錄； 與外部儲存的操作； 目錄之間的rsync； 備份輪換（刪除舊副本）
- 呼叫外部腳本
- 手動執行單獨的任務
/opt/KristaBackup/KristaBackup.py run make_full_dump - 您可以為 crontab 新增（或刪除）單一任務或整個計劃
/opt/KristaBackup/KristaBackup.py enable all - 根據備份結果產生觸發檔案。 該功能與Zabbix結合用於監控備份很有用
- 可以在 webapi 或 web 模式下在後台工作
/opt/KristaBackup/KristaBackup.py web start [--api]
模式之間的差異：webapi 本身沒有 Web 介面，但應用程式會回應來自另一個實例的請求。 對於 Web 模式，您需要安裝 Flask 和幾個附加軟體包，但這並不是在任何地方都可以接受的，例如在經過認證的 AstraLinux SE 中。
透過Web介面，您可以查看連接伺服器的備份狀態和日誌：「Web實例」透過API從「備份實例」請求資料。 存取web需要授權，存取webapi則不需要。
不正確備份的日誌以顏色標記：警告 - 黃色，錯誤 - 紅色。
如果管理員不需要參數備忘單且伺服器作業系統是同類的，則可以編譯該檔案並分發現成的套件。
我們主要透過 Ansible 分發此實用程序，首先將其推廣到一些最不重要的伺服器，然後在對其餘所有伺服器進行測試後。
結果，我們收到了一個緊湊的、獨立的複製實用程序，它可以自動化，甚至可以由沒有經驗的管理員使用。 這對我們來說很方便——也許對您也有用？
來源： www.habr.com