多くのことが蓄積されたので、記録、役立つリンク、個人的な経験を共有することにしました。
データベースのバックアップを整理する際の最も一般的なエラー （ citrin.ru/backup.htmlから取得 ）
-これらの原則は、データベースだけでなく、一般的なバックアップにも適用されます。
PostgreSQLの本からの抜粋。 開発者および管理者ガイド。 Geschwind、Shenig基本的に、データベースサーバーを使用する場合、6つのエラーがあります。
-Friskyのコピーは通常ありません。
言うまでもなく、これは確かに深刻な問題につながります。
-バックアップは作成されましたが、リカバリプロセスはテストされていません。
おそらくこれは、バックアップを操作する際に犯される最も重大な間違いの1つです。 管理者はバックアップコピーを作成し、予期しないイベントからデータを確実に保護します。 ただし、リカバリの仕組みがわからない場合は、緊急時に深刻な問題に直面する可能性があります。 以前にリカバリが検証されたことがない場合、管理者はリカバリプロセス中に不安を感じ、その結果、追加の時間損失とエラーが発生します。 バックアップからデータを回復する方法を十分に知っていることを確認してください。 これは非常に重要な側面であり、ほとんどのユーザーと管理者は単に忘れています。
-バックアップを作成しますが、それらを知っている人以外は誰もいません。
一般的に、車は人よりも信頼性が高いです。 これは、データベースシステムとバックアップ戦略を設計するときに考慮する必要があります。 過去数年間に対処しなければならなかった多くの組織では、非常に危険な傾向が見られました：システムの状態に関するすべての情報を持っているのは、バックアップまたは情報システム全体の責任者だけでした。 そして、この人が休暇をとったり、組織を辞めようと決めた場合はどうなりますか？ このような状況では、多くの組織が深刻な課題に直面する可能性があります。 情報システムの冗長性と信頼性の程度に関係なく、その仕組みと緊急事態で何をすべきかを誰も知らない場合、組織は大きなトラブルに直面します。 システムを操作する人員が互いに交換できることは、機器の冗長性と同じくらい重要です。 情報システムにはすべての重要なプロセスの文書が必要であり、何人かの人々はシステムの仕組みを知っている必要があります。 お金を節約しようとして、多くの組織はドキュメントを無視していますが、ほとんどの場合、リカバリプロセスは短いドキュメントを作成するよりも高価です。 結論として、ドキュメントは使用可能な状態に維持する必要があることに注意してください。
-バックアップは、元のデータと同じメディアに作成されます。
過去数年間で、さらにいくつかの不穏なシナリオに遭遇しました。 バックアップコピーが元のデータと同じメディアに保存されているバックアップシステムを確認する必要がありました。 ハードドライブが動作を停止する状況を想像してください。 それでもバックアップを読むことができれば、とても幸運です。 ほとんどの場合、これは不可能です。 バックアップとソースデータは異なるメディア上にある必要があります。 そうしないと、復旧しようとしたときに問題が発生します。
-バックアップとソースデータは1つの部屋に保存されます。
火災の場合、データの1つのバージョンを別の部屋に保管することが重要です。 そうしないと、データとバックアップが破壊される可能性があります。 この場合、データは完全に失われ、復元は不可能です。
-最新のバックアップのみ。
最新のバックアップのみが存在すると、問題が発生する可能性があります。 ほとんどの場合、誤動作の正確な発生時刻は不明であるため、最新のバックアップにもエラーが含まれ、リカバリが困難になります。
便利なリンク：
www.ibm.com/developerworks/en/library/l-backup/index.html-Linux Backup Automation
www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/backup-basics.html-バックアップ技術の基礎
en.wikipedia.org/wiki/Back_list_to_backup
en.wikipedia.org/wiki/Rsync
rsync.samba.org/examples.html
www.fredshack.com/docs/rsync.html
everythinglinux.org/rsync
howtoforge.org/rsync_incremental_snapshot_backups
www.mikerubel.org/computers/rsync_snapshots
www.debianhelp.co.uk/backup.htm
www.linux-backup.net
私の選択：
フレックスバックアップ
flexbackup.sourceforge.net
gentoo-wiki.com/HOWTO_Backup-非常に賢明なドック、何をすべきか、どのように。
選択された差分バックアップ、増分バックアップ、完全バックアップが可能です。
構文は非常に柔軟で、包含/除外マスクです。 アーカイバの幅広い選択。
Tolesaは単一ホストのバックアップシステムとして位置付けられています（これが必要です）。
差分バックアップ-後続のすべてのバックアップが完全バックアップの作成以降に発生した変更のみをバックアップする場合のこのタイプのバックアップ。
このように：
#monthly full backup
30 2 1 * * flexbackup -set all -full
#daily differential backups
0 5 2-31/3 * * flexbackup -set all -differential
1か月に1回、完全バックアップが作成され、3日ごとに、完全バックアップと比較して差分コピーが作成されます。
そのため、バックアップはあまり蓄積されませんが、少なくとも今月と前月のバックアップがあります。
# Deleting all backups older then 60 days
30 1 1 * * find /mnt/backups/`hostname -s`/flexbackup.0/ -name "*.tar" -a -mtime +60 -delete
もちろん、flexbackup.confでは、このディレクトリ（/ mnt / backups / `hostname -s` / flexbackup.0 /）にファイルを保存することが示されており、バックアップタイプ「tar」も設定されています
バックアップシステムは、個別のホスト上ですべて構成されます。
次に、sshキーとrsyncを使用して、リモートサーバーのバックアップディレクトリを中央のバックアップストレージサーバーと同期します。
すべてが標準ツールからシンプルですが、効果的です;）
注意：
これはすべてLinuxで作成およびテストされました。 FreeBSDでは、このシステムも機能しますが、少なくともスクリプトでは、PATH環境変数を指定する必要があります。