主持人 > 博客 > 管理 > GitLab 如何協助您備份大型 NextCloud 存儲

GitLab 如何協助您備份大型 NextCloud 存儲

嘿哈布爾！

今天我想談談我們在不同配置下從 Nextcloud 儲存自動備份大數據的經驗。 我在 Molniya AK 擔任服務站，負責 IT 系統的配置管理；Nextcloud 用於資料儲存。 包括，具有分散式結構，具有冗餘性。

由於安裝的特點而產生的問題是數據量很大。 Nextcloud 提供的版本控制、冗餘、主觀原因等會造成許多重複。

底

管理 Nextcloud 時，會出現組織有效備份的問題，必須對備份進行加密，因為資料很有價值。

Мы предлагаем варианты хранения бэкапа у нас или у заказчика на его отдельных от Nextcloud машинах, что требует гибкого автоматизированного подхода к администрированию.

客戶端有很多，它們都有不同的配置，並且都在自己的網站上並且具有自己的特點。 當整個網站都屬於您並且由皇冠製作備份時，這是一種標準技術；它不太適合。

Для начала посмотрим на вводные данные. Нам нужно:

  • 一個或多個節點的可擴展性。 對於大型安裝，我們使用 minio 作為儲存。
  • 了解執行備份時遇到的問題。
  • 您需要與您的客戶和/或我們一起保留備份。
  • Быстро и легко разбираться с проблемами.
  • 客戶端和安裝彼此之間有很大不同 - 無法實現統一。
  • 在兩種情況下恢復速度應該是最低的：完全恢復（災難）、一個資料夾被錯誤刪除。
  • 需要重複資料刪除功能。

GitLab 如何協助您備份大型 NextCloud 存儲

為了解決管理備份的問題，我們安裝了GitLab。 更多詳細資訊請參閱tackle。

當然，我們並不是第一個解決此類問題的人，但在我們看來，我們來之不易的實際經驗可能很有趣，並且我們準備好分享它。

由於我們公司有開源政策，因此我們一直在尋找開源解決方案。 反過來，我們也會分享並發布我們的進度。 例如，在 GitHub 上有 наш плагин для Nextcloud, который мы ставим клиентам, усиливающий сохранность данных на случай случайного или преднамеренного удаления.

Средства бэкапирования

Поиск методов решения мы начали с выбора средства создания бэкапа.

常規 tar + gzip 效果不佳 - 數據是重複的。 增量通常包含很少的實際更改，並且單個文件中的大部分資料都是重複的。
還有一個問題——分散式資料儲存的冗餘。 我們使用minio，它的資料基本上是冗餘的。 或者您必須透過 minio 本身進行備份 - 加載它並使用檔案系統之間的所有間隔符，並且同樣重要的是，存在忘記某些儲存桶和元資訊的風險。 或使用重複資料刪除。

具有複製功能的備份工具可在開源中取得（在 Habré 上有 文章 關於這個主題）我們的決賽入圍者是 博格 и 雷斯蒂奇。 我們對這兩個應用程式的比較如下，但現在我們將告訴您我們如何組織整個計劃。

管理備份

Borg 和 Restic 都不錯，但這兩個產品都沒有集中控制機制。 出於管理和控制的目的，我們選擇了一個我們已經實現的工具，沒有它我們無法想像我們的工作，包括自動化——這就是眾所周知的 CI/CD - GitLab。

想法是：在每個儲存Nextcloud資料的節點上安裝gitlab-runner。 運行程序按計劃運行一個腳本來監視備份過程，並啟動 Borg 或 Restic。

我們得到了什麼？ 來自執行的回饋、對變更的便利控制、發生錯誤時的詳細資訊。

這裡 在 GitHub 上 我們發布了用於各種任務的腳本範例，最終我們不僅將其附加到 Nextcloud 的備份中，還附加到許多其他服務的備份中。 如果您不想手動配置它（我們也不想），還有一個調度程序和 .gitlab-ci.yml

目前還沒有辦法在 Gitlab API 中更改 CI/CD 逾時，但它很小。 它需要增加，比如說 1d.

GitLab к счастью умеет запускать не только по коммиту, но только по расписанию, это ровно то что нам надо.

現在介紹包裝腳本。

Мы поставили такие условия для этого скрипта:

  • 它應該由跑步者啟動並從具有相同功能的控制台手動啟動。
  • 必須有錯誤處理程序：
  • 返回代碼。
  • 在日誌中搜尋字串。 例如，對我們來說，錯誤可能是程式不認為是致命的訊息。
  • 處理超時。 交貨時間必須合理。
  • 我們需要一個非常詳細的日誌。 但僅限於出現錯誤時。
  • 在開始之前還要進行一些測試。
  • 為了方便起見，我們發現在支援過程中很有用的小額獎金：
  • 開始和結束記錄在本機的 syslog 中。 這有助於連接系統錯誤和備份操作。
  • 部分錯誤日誌（如果有）輸出到 stdout，整個日誌寫入單獨的檔案。 如果錯誤很小，那麼立即查看 CI 並評估錯誤是很方便的。
  • 調試模式。

完整日誌會作為工件保存在 GitLab 中；如果沒有錯誤，則刪除日誌。 我們在 bash 中編寫腳本。

我們很樂意考慮任何有關開源的建議和意見 - 歡迎。

Какэтоработает

具有 Bash 執行器的運行器在備份節點上啟動。 根據調度程序，作業 CI/CD 是在一個特殊的蘿蔔中啟動的。 執行程式為此類任務啟動一個通用包裝腳本，它檢查備份儲存庫、掛載點和我們想要的所有內容的有效性，然後備份並清理舊的。 完成的備份本身將發送到 S3。

Мы работаем по такой схеме — это внешний провайдер AWS или российский аналог (это быстрее и данные не покидают РФ). Либо клиенту ставим отдельный minio кластер на его площадке для этих целей. Обычно так делаем по соображениям безопасности, когда клиент совсем не хочет чтобы данные покидали их контур.

Пользоваться фичей отправки бэкапа по ssh мы не стали. Безопасности это не добавляет, а сетевые возможности провайдера S3 сильно выше одной нашей ssh машины.

為了保護您的本地電腦免受駭客攻擊，因為他可以刪除 S3 上的數據，因此您必須啟用版本控制。
備份始終對備份進行加密。

Borg 有未加密模式 none，但我們強烈不建議打開它。 在這種模式下，不僅不會加密，而且不會計算正在寫入的內容的校驗和，這意味著只能使用索引間接檢查完整性。

單獨的調度程序檢查備份的索引和內容的完整性。 檢查速度慢且時間長，因此我們每月單獨運行一次。 可能需要幾天時間。

俄語自述文件

主要功能

  • prepare 訓練
  • testcheck 準備狀況檢查
  • maincommand 核心團隊
  • forcepostscript 最終執行或錯誤執行的函數。 我們用它來卸載分區。

服務功能

  • cleanup 我們記錄錯誤或刪除日誌檔案。
  • checklog 解析日誌中是否存在錯誤行。
  • ret exit handler.
  • checktimeout 檢查是否超時。

環境

  • VERBOSE=1 我們立即在螢幕上顯示錯誤（標準輸出）。
  • SAVELOGSONSUCCES=1 成功後保存日誌。
  • INIT_REPO_IF_NOT_EXIST=1 如果儲存庫不存在，則建立它。 預設禁用。
  • TIMEOUT максимальное вермя на основную операцию. You can set it as ‘m’, ‘h’ or ‘d’ at the end.

舊副本的儲存模式。 預設:

  • KEEP_DAILY=7
  • KEEP_WEEKLY=4
  • KEEP_MONTHLY=6

Переменные внутри скрипта

  • ERROR_STRING — 用於檢查錯誤日誌的字串。
  • EXTRACT_ERROR_STRING — 若出錯則顯示字串的表達式。
  • KILL_TIMEOUT_SIGNAL — 若逾時則發出終止訊號。
  • TAIL — 螢幕上有多少個字串有錯誤。
  • COLORMSG — 訊息的顏色（預設黃色）。

該腳本名為 wordpress，有一個條件名稱，它的技巧是它還備份 mysql 資料庫。 這意味著它可用於單節點 Nexcloud 安裝，您也可以在其中備份資料庫。 方便之處不僅在於所有內容都集中在一處，而且資料庫的內容與文件的內容很接近，因為時間差很小。

雷斯蒂奇 vs 博格

Сравнения Borg и Restic есть в том числе 這裡是哈布雷, и у нас не было задачи сделать просто еще одно, но своё. Нам было важно как это будет выглядить на наших данных, с нашей спецификой. Мы их приводим.

除了已經提到的（重複資料刪除、快速恢復等）之外，我們的選擇標準：

  • Устойчивость к незавершенной работе. Проверка на kill -9.
  • 磁碟上的大小。
  • Требовательность к ресурсам (ЦПУ, память).
  • 儲存的 blob 的大小。
  • 使用 S3。
  • Проверка целостности.

Для тестирования мы взяли одного клиента с реальными данными и общим размером 1,6Тб.
條件。

Borg не умеет напрямую работать с S3, и мы монтировали как fuse диск, через 高飛。 Restic 將其發送到 S3 本身。

Goofys 工作得非常快而且很好，而且有 модуль дискового кеша, что еще больше ускоряет работу. Он находится в стадии beta, и, признаться, у нас падал с потерей данных на тестах (других). Но удобство в том, что сама процедура бэкапа не требует большого чтения, а в основном запись, поэтому кеш мы используем только во время проверки целостности.

為了減少網路的影響，我們使用了本地提供者 - Yandex Cloud。

對比測試結果。

  • Kill -9 並進一步重新啟動均成功。
  • 磁碟上的大小。 Borg可以壓縮，所以結果符合預期。

備份器
大小

博格
562Gb

雷斯蒂奇
628Gb

  • По CPU
    Borg本身消耗很少，採用預設壓縮，但必須與goofys進程一起評估。 總的來說，它們具有可比性，並且在同一台測試虛擬機器上使用大約 1,2 個核心。
  • 記憶。 Restic約0,5GB，Borg約200MB。 但這與系統檔案快取相比，都是微不足道的。 所以建議分配更多的記憶體。
  • 斑點大小的差異是驚人的。

備份器
大小

博格
約500MB

雷斯蒂奇
約5MB

  • Restic S3 的體驗非常棒。 透過 goofys 使用 Borg 不會產生任何問題，但有人指出，建議在備份完成後執行 umount 以完全重置快取。 S3 的特點是，未充分泵送的區塊永遠不會被發送到桶中，這意味著未完全填充的資料會導致重大損壞。
  • 完整性檢查在這兩種情況下都運作良好，但速度差異很大。
    雷斯蒂奇 3,5小時.
    Borg，具有 100GB SSD 檔案快取 – 5小時如果資料位於本機磁碟上，速度結果大致相同。
    Borg直接從S3讀取，無需緩存 33小時. Чудовищно долго.

最重要的是，Borg 可以壓縮並具有更大的 blob，這使得 S3 中的儲存和 GET/PUT 操作更便宜。 但這是以更複雜和更慢的驗證為代價的。 至於恢復速度，我們沒有發現任何差異。 Restic 的後續備份（在第一個備份之後）時間會稍長一些，但並不明顯。

最後但並非最不重要的選擇是社區的規模。

我們選擇了博格人。

Пару слов о сжатии

У Borg’а есть в арсенале прекрасный новый алгоритм сжатия — zstd. По качеству сжатия не хуже gzip, но значительно быстрее. И сравним по скорости с дефотным lz4.

例如，在相同速度下，MySQL 資料庫轉儲的壓縮效果是 lz4 的兩倍。 然而，實際數據的經驗表明，Nextcloud節點的壓縮率差異很小。

Borg 有一個相當獎勵的壓縮模式 - 如果檔案具有高熵，則根本不應用壓縮，這會提高速度。 建立時透過選項啟用
-C auto,zstd
對於 zstd 演算法
因此，使用此選項，與預設壓縮相比，我們得到
分別為 560Gb 和 562Gb。 我提醒您一下，上面範例中的數據，未經壓縮的結果是 628Gb。 2GB差異的結果讓我們有些驚訝，但我們認為我們最終還是會選擇它。 auto,zstd.

備份驗證方法

根據調度程序，虛擬機器直接從提供者或用戶端啟動，大幅減少了網路負載。 至少比自己養、拉流量便宜。

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

По этой же схеме мы проверяем файлы антивирусом (постфактум). Ведь пользователи заливают разное в Nextcloud и не у всех есть антивирус. Проводить проверку в момент заливки занимает слишком много времени, и мешает бизнесу.

可擴展性是透過在具有不同標籤的不同節點上運行運行器來實現的。
我們的監控透過一個視窗中的 GitLab API 收集備份狀態；如有必要，問題很容易被發現，也很容易定位。

結論

因此，我們確信我們進行了備份，我們的備份是有效的，備份中出現的問題只需要很少的時間，並且可以在值班管理員的層級上解決。 與 tar.gz 或 Bacula 相比，備份佔用的空間非常小。

來源： www.habr.com

添加評論