こんにちは、Habr！
私の名前はナタリアです。私はNPOCristaのアプリケーション管理者グループのチームリーダーです。私たちは、当社のプロジェクトグループのOpsです。私たちにはかなり独特な状況があります。私たちは、会社のサーバーとクライアントの敷地内にあるサーバーの両方にソフトウェアをインストールして保守しています。この場合、サーバー全体をバックアップする必要はありません。重要なのは「必須データ」、つまりファイルシステムのDBMSと個々のディレクトリだけです。もちろん、顧客は独自のバックアップ手順を持っている（または持っていない）ため、バックアップを保存するための何らかの外部ストレージを提供することがよくあります。この場合、バックアップを作成した後、外部ストレージへの送信を提供します。
しばらくの間、バックアップの目的でbashスクリプトを使用しましたが、オプションが増えるにつれて、このスクリプトの複雑さは比例して増大し、ある時点で「それを地面に破壊してから....」必要になりました。
既製のソリューションは、バックアップを分散化する必要があるため、クライアントにローカルにバックアップを保存する義務があるため、セットアップの複雑さ、インポートの置換、アクセス制限など、さまざまな理由で機能しませんでした。
自分で何かを書くほうが簡単だと私たちには思えました。同時に、私は次のN年間の状況に十分であるが、範囲の潜在的な拡大の可能性がある何かを手に入れたかった。
問題の条件は次のとおりです。
- 基本的なバックアップインスタンスは自律的で、ローカルで機能します
- 常にクライアントのネットワーク内にバックアップとログを保存する
- – «»
- Linux, ,
- ssh,
- ( ) ,
ここで得られたものを見ることができます：github.com/javister/krista-backup
ソフトウェアはpython3で書かれています。Debian、Ubuntu、CentOS、AstraLinux1.6で動作します。
ドキュメントは、リポジトリのdocsディレクトリにあります。
システムで使用される基本概念：
アクション-1つのアトミック操作（データベースバックアップ、ディレクトリバックアップ、ディレクトリAからディレクトリBへの転送など）を実装するアクション。既存のアクションはコア/アクションディレクトリ
タスクにあります-タスク、1つの論理的な「バックアップタスク」
スケジュールを説明する一連のアクション-スケジュール、タスク実行時間をオプションで示すタスクセット
バックアップ構成はyamlファイルに保存されます。一般的な構成構造：
- 一般設定
- セクションアクション：このサーバーで使用されるアクションの説明
- スケジュールセクション：すべてのタスク（一連のアクション）の説明と、そのような起動が必要な場合は、クラウンによる起動のスケジュール
構成の例はここに
ありますアプリケーションが現時点でできること：
- 主な操作は次のとおりです。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モードの場合、フラスコといくつかの追加パッケージをインストールする必要がありますが、これは、認定されたAstraLinux SEなど、どこでも受け入れられるわけではありません。
Webインターフェイスを介して、接続されたサーバーのバックアップのステータスとログを表示できます。「Webインスタンス」は、APIを介して「バックアップインスタンス」からデータを要求します。 Webへのアクセスには許可が必要ですが、webapiへのアクセスには必要ありません。
誤って渡されたバックアップのログは、警告-黄色、エラー-赤の色でマークされます。
管理者がパラメータに関するチートシートを必要とせず、サーバーオペレーティングシステムが同種である場合は、ファイルをコンパイルして既製のパッケージを配布できます。
このユーティリティは主にAnsibleを通じて配布され、最初に重要度の低いサーバーに展開され、テスト後に他のすべてのサーバーに展開されます。
その結果、コンパクトなスタンドアロンのコピーユーティリティが得られ、自動化が容易で、経験の浅い管理者でも使用できます。それは私たちにとって便利です-多分それはあなたにとって役立つでしょう？