バックアップ システムは数多くありますが、サービスを提供するサーバーがさまざまな地域やクライアントに分散しており、オペレーティング システムで対応する必要がある場合はどうすればよいでしょうか?
良い一日、 ハブル!
私の名前はナタリアです。 NPO法人クリスタのアプリケーション管理者グループのチームリーダーをしています。 私たちは会社のプロジェクトグループのOpsです。 当社の状況はかなり特殊です。当社のサーバーとクライアントのサイトにあるサーバーの両方にソフトウェアをインストールして保守しています。 この場合、サーバー全体をバックアップする必要はありません。 重要なのは「必須データ」、つまり DBMS と個々のファイル システム ディレクトリだけです。 もちろん、クライアントには独自のバックアップ規則がある (またはない) ため、バックアップを保存するために何らかの外部ストレージを提供することがよくあります。 この場合、バックアップを作成した後、必ず外部ストレージに送信します。
しばらくの間、バックアップの目的で bash スクリプトを使用していましたが、構成オプションが増えるにつれて、このスクリプトの複雑さも比例して増大し、ある時点で「スクリプトを徹底的に破壊し、その後、 ...」。
既製のソリューションは、バックアップを分散する必要性、バックアップをクライアントでローカルに保存する必要性、セットアップの複雑さ、インポートの置換、アクセス制限など、さまざまな理由で適していませんでした。
自分たちで何かを書くほうが簡単だと私たちには思えました。 同時に、今後 N 年間の状況に十分対応できる、ただし範囲を拡大できる可能性のあるものを入手したいと考えていました。
課題の条件は以下の通りでした。
- 基本的なバックアップ インスタンスは自律的であり、ローカルで実行されます。
- バックアップとログのストレージは常にクライアントのネットワーク内にあります
- インスタンスはモジュール (一種の「コンストラクター」) で構成されます。
- 古いものを含む現在の Linux ディストリビューションとの互換性が必要であり、潜在的なクロスプラットフォームが望ましい
- インスタンスを操作するには、ssh 経由でアクセスするだけで十分です。追加のポートを開く必要はありません。
- セットアップと操作が最大限に簡単
- 異なるサーバーからのバックアップのステータスを一元的に表示できるようにする別のインスタンスを用意することも可能です (必須ではありません)。
ここで私たちが考え出したものを見ることができます:
ソフトウェアは python3 で書かれています。 Debian、Ubuntu、CentOS、AstraLinux 1.6 で動作します。
ドキュメントはリポジトリの docs ディレクトリに投稿されます。
システムが動作する基本概念:
アクション – XNUMX つのアトミック操作 (データベース バックアップ、ディレクトリ バックアップ、ディレクトリ A からディレクトリ B への転送など) を実装するアクション。 既存のアクションは core/actions ディレクトリにあります
task - タスク、XNUMX つの論理的な「バックアップ タスク」を記述する一連のアクション
スケジュール – スケジュール、タスクの実行時間をオプションで示す一連のタスク
バックアップ構成は yaml ファイルに保存されます。 一般的な構成構造:
- 一般設定
- アクションセクション: このサーバーで使用されるアクションの説明
- スケジュール セクション: すべてのタスク (アクションのセット) の説明と、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 を通じて配布され、最初に重要性の低いサーバーの一部に展開され、テスト後に残りのすべてのサーバーに展開されます。
その結果、自動化でき、経験の浅い管理者でも使用できるコンパクトなスタンドアロン コピー ユーティリティが完成しました。 それは私たちにとって便利ですが、もしかしたらあなたにとっても役立つかもしれません?
出所： habr.com