管理者は、まだバックアップを行わない人とバックアップをすでに行う人に分かれていることを誰もが知っています。 ただし、バックアップが行われていると確信している人はまだいるという意見がありますが、実際にはそうではありません。 この投稿では、いくつかの実際のストーリーを語り、（可能であれば）検討し、結論を出したいと思います。
免責事項：すべての話は真実ですが、一部の場所では端が切れており、会社と管理者のイメージは集合的であり、すべての名前が変更され、顔は認識できないほど歪んでいます、私の最初のトピック、何とか何とか...
はじめに：会社を開発者の古典的な会社と考えてみましょう：バージョン管理システム（この場合はサブバージョンが重要です）、バージョンアセンブリシステム、および売上高とウィキのシステムの負荷を積極的に使用します。 ボリュームは大きく、データの損失には多額の費用がかかります。すべてが「時計のように」機能し、「突然の火災」が誰にもわからないようにする必要があります。データを保存する必要があります。 バックアップが自動的に作成された後、バックアップがマグに落ちると仮定します。 テープ/ DVDはスイスの銀行のゼネラルディレクター/セルの金庫に保管されているため、最新のバックアップが利用できるかどうかは問題ありません。
ストーリー回数
昼食前
管理者は、バックアップデータベースを作成するスクリプトを作成し、これについてログに書き込みます。
ドラマ
-シェフ、すべてなくなった、シェフ！
-問題ありません、バックアップがあります！ potを生やしたものはどこですか？
管理者は、date_timeフォルダーにきちんと折りたたまれたバックアップからダンプを選択し、半年後から始まるダンプファイルのサイズがゼロであることを確認します。
雷雨の後
間違いは少なくとも面白かった。 代わりに
mysqldump db > db.sql &2>> log.txt
書かれた
mysqldump db > db.sql &>> log.txt
実際、ログエントリが>>を使用して正確に追加され、状況を保存したという事実は、最悪の事態を回避するのに役立ちましたが、これはもちろん非常に大きな成功です。 エラーが検出され、サイズが10ギガバイトのlog.txtファイルが、ファイルの終わり近くに必要な行を見つけてダンプを展開する手法の問題でした。
ストーリーナンバー2
昼食前
管理者は、svnadminを使用してリポジトリ全体をダンプし、バックアップサーバーにコピーをスローするスクリプトを作成します。 「そして、もしどこがおかしいのか」「履歴の回数」から正しい結論を出した後、管理者は、そのような日にリポジトリが非常に多くのバイトのために予約されたというログを追加します。
ドラマ
実際、ドラマは回避されましたが、幸運にも、すべてが著しく悪化する可能性があります。 私は2番目のsvnサーバー、ある種のサンドボックスを作りたかったのですが、少し後に、1日に1回、最新のダンプをロールバックしたかったのです。 この問題を解決する際、管理者はリポジトリダンプファイルがいつか壊れていることを発見しました。 同時に、サイズチェックに成功しました-すべてのリビジョンがこの重要なリビジョンにバックアップされました。
雷雨の後
今回はsvnadminのせいで、最初のリビジョンから開始して、完全バックアップを繰り返し作成しました。 途中のある種の改訂はコウモリでしたが、svnadminはそれに到達し、壊れて、正直に通知して内部に入りました。 ここから始めて、残念ながら、私は知りませんが、それらは私たちにとってあまり重要ではありません。 リビジョンを修正する方法も、削除する方法もありませんでした（ところで、最新バージョンのSubversionでこれがどのように機能するかはわかりません）。 そのため、rsyncを使用して毎日巨大なリポジトリをサンドボックスに移植するという司令官の決定が下されました。
ここで要約する必要があります
このすべてに私は何を言いたいのですか？ 個人的には、バックアップが成功したという意思決定プロセスを自動化することは非常に困難です。 つまり 成功したとしましょうが、このバックアップを展開せずに、その中のデータが正しく最新であることをどのように確認できますか？ そして、たとえば、新しいデータは、しばらくしてからバックアッププロセス自体を中断し始めませんか？ さらに、これにつながるエラーは世界と同じくらい古い可能性があります。
- 人的要因
- ツールの不安
- チェックのロジックのエラー
- その他
個人的には、上記の質問に対する答えがわかりません。 尊敬されているハブラーが知っているなら、私の経験を共有してすみません。
それまでの間、少なくともバックアップの場合は、「作られ忘れられた」原則が機能しないと長い間信じていました。 そのような機会がある場合は、バックアップを完全に別のテストサーバーに展開することをお勧めします（ここでは、バックアップの展開時間を記述することで1石で2羽の鳥を殺します）。 または、別のバックアップ整合性チェックスクリプトを記述します。 以下を確認する必要があります。
- バックアップ作成日
- ファイルサイズ
- 前回のバックアップからのファイルサイズの変更
- バックアップ内のファイルのリスト（または少なくとも一意のファイルの数）
- ...そして、これらすべての情報を1日に1回メールに蓄積して送信します。
ご清聴ありがとうございました。
UPDカルマをありがとう=>ブログ「システム管理」に移行しました。