私たちは、世界の反対側(Linodeによってホストされている)でリモートに実行されているDebianサーバー上のすべてを、シャットダウンせずにバックアップしたいと考えています。
このシステムは、いくつかの単純なnginx設定で、シェル、電子メール、XMPP/prosody、およびWebを実行しています。
私たちは安全のためにそれらに関連するファイルをバックアップしたいと考えています。たとえば、ユーザーがホームディレクトリに保存したファイル。
すべての/ etcファイルに対して既存のセットアップを正確にコピーする必要はありません。代わりに、そもそもバックアップを行うのは、すべてを新しいセットアップに移動できるようにするためです(新しいバージョンのDebianはまだLinodeにあります)。
Linodeがバックアップサービスを提供していることを確認します。しかし、長期的には、自分自身のバックアップも必要です。ここでは、バックアップが失敗したり、何か奇妙なことが起こった場合に備えています。
この質問が存在する理由は、過去にバックアップを作成しようとしたときに、次の2つの誤りのいずれかを犯し続けているためです。
/
とその下にあるすべてのものをコピーする」に行った後、コピー先のドライブが/ media/backupにマウントされていて、それ自体を再帰的にコピーしていたため、奇妙な無限ループに陥りました[ rsyncなどでバックアップするため、ここでは該当しない特定の問題]または、/ procや/ varなどの「生きている」ものをコピーしようとしてスタックし、変化し続けるログに対応しようとしている、または/var
の下)、および/etc
のコピーと/の下のすべての古いメールを手に入れましょうvar/vmail」と入力した後、常にファイルのアクセス許可またはタイムスタンプを変更しました(今回はUNIXファイルをFATドライブにバックアップしないようにします)、または何かを忘れました(「ああ、シュート、カスタムスクリプトを/に入れましたどこにも保存したことのないusr/local/binです。それらを取得するのを忘れていました。したがって、ドライブ全体をまっすぐにコピーすると、落とし穴が生じ、ディレクトリを選択的にコピーすると落とし穴が生じます。私はそれを正しく行う方法を知りたいです。
サーバー障害の質問 完全なバックアップシステムに必要なもの は、哲学と優れた実践をカバーしていますが、以下のより具体的な詳細を探しています。
rsync -HXaz
私たちにとって良い選択肢だと思いますか? -z
obvは、「何を保存するか」という質問に実際には関連していません。dd
の使用など、バックアップに関するアドバイスの多くは、ドライブがマウントされておらず、使用されていないことを前提としているようです。しかし、/ procのような「生きている」ディレクトリや/ varの下のいくつかのサブディレクトリを除外するつもりはありません(ただし、/ varの下にあるもののいくつかは、私たちが確実に知っているdo必要です保持する)と/ mount?この状況で他に何を考える必要がありますか?次に、rsyncを使用して、--exclude
フラグの束を使用するだけで、それを削ることができると思います。
それとも、より良いアイデア、特にFOSSフレンドリーなアイデアはありますか?
それで、これらの厄介な間違いをせずにすべてのドライブをバックアップし、すべての/ procおよびその他の一時フォルダを除外したいですか?
オプションは、次のようにルートフォルダーをファイルシステム内の別のフォルダーにマウントすることです。
$ cd /mnt
$ mkdir drive
$ mount --bind / drive
これにより、ドライブにある一時ファイルと見なされないすべてのファイル(/ procまたは/ sysフォルダーなど)が提供されます。
ルートフォルダーがきれいに表示されたので、標準のcp
またはrsync
を使用して、それをバックアップドライブにコピーできます。以下に沿ったもの:
cp -R /mnt/drive /mnt/backupdrive
これはあなたが言及した両方の問題を解決します:
参照: man mount(8)
Linuxでは、すべてがファイルです。 rsyncを使用することもできますが、(せいぜい)回避するのが難しいことに注意する必要があります。
特にデータベースの場合は、まずレプリケーションについて考える必要があります。また、これは、プライマリサーバーの前にプロキシ/ロードバランサーを設定することをお勧めします。これにより、移行中にプライマリサーバーとミラーサーバーを簡単に切り替えることができます。
ハードウェアレベルでの最良の状況は、同じ数のイーサネットポート、同じhddレイアウトなどを備えたミラーのようなサーバーを別の側に置くことです。異なるものはすべて、システム構成を変更する必要があることを意味します。
つまり、2つのethポートがある場合、ネットワーク構成、ファイアウォールなどが両方のサーバーのインターフェース名と一致することを確認します。異なる場合は、rsync後に構成を変更するか、2番目のデバイス名を変更する必要があります。 (宛先)サーバー。
パーティションレイアウトと同じです。プライマリサーバーと同じパーティションを作成する必要がありますが、最初から作成すると異なるUUIDが作成されるため、fstab、grub、mdadm(soft-raidが関係する場合)などを変更する必要があります。 。
ただし、データベースなど、以前に(rsyncを実行する前に)停止しないと一貫性が失われる可能性のある、多くの問題が発生する可能性もあります。
最善の戦略は、最初にハードウェアとファイルシステム(パーティション)を準備することです-プライマリサーバーの構成に一致させます。次に、中間システムを介して空のパーティションをマウントします(ssh-serverが一時的にインストールされたライブCDなど)。次のように、空の/ proc、/ dev、/ sysを作成し、残りをrsyncします。
rsync -avz -H --delete /etc /bin (...and so on) destserver:/mnt/yourrootfs/
次に、デバイスにgrubをインストールして構成を操作し、デバイスを起動可能にして、ネットワーク構成、fstab、および前述のその他のものを変更する必要があります。
また、(プライマリサーバーで使用しているものと同じバージョンの)新しいシステムをインストールし、電源を切り、別の一時的なシステム(ライブCDなど)を介してマウントし、/ proc、/以外のものを交換することもできます。 sys、/ dev、および/ bootとrsync。
しかし、それは一般的な考えにすぎません。このサーバーに実際に何があるか、構成、ネットワーク、ハードウェアの設定によっては、状況が複雑になる場合があります。そして結局のところ、顕著なダウンタイムなしにこれを実行することは、本当に困難または不可能かもしれません。
実際に必要なのはリストアです。何をするにしても、定期的にテストを復元する必要があります。
Linodeにはバックアップサービスがあります。 スナップショットは、事前定義された限られたスケジュールで、またはAPIを使用して作成できます。
スナップショットベースのバックアップの利点は、コピーが作成されている間、データが変更されないため、特定の時点を提供できることです。スナップショットは、別のホスト(この場合は新しいLinode)に簡単に復元することもできます。
ZFSでシステムを実行します。次に、以下のようなものを使用して、瞬時のアトミックスナップショットを取得できます。
# zfs snap -r tank@name-of-backup
ここで、tank
はZFSプールの名前です。このスナップショットは、ファイルシステムとそのすべての子ファイルシステムの瞬間的な瞬間スナップショットであることが保証されています。
スナップショットを作成したら、zfs send
およびssh
を使用して別のホストに転送できます。
私は小さな仮想プライベートサーバーにBackupPCを使用していますが、これはかなりうまく動作します。 BackupPCは内部でrsyncを使用でき、完全バックアップと増分バックアップをサポートしています。それを見て、それがあなたの要件をカバーするかどうかを確認してください。
私の意見は、内部Linuxコマンドでサーバーを実行している場所と場所によって異なります。完全なデータとライブラリを模倣/パイプする必要があります。 VMwareで実行し、適切に構成すると、ライブマイグレーションが提供されます。または、サードパーティのツールを使用する必要があります。これがお役に立てば幸いです。その他の参考資料 ライブサーバーのバックアップを作成するにはどうすればよいですか?
Rsyncは、サーバー間でデータを同期するための優れたコマンドです。
チェックリストが不完全であったり、見落としがあったために、リストから1つの項目を欠落するだけでなく、欠けているビットに(もう)依存する必要がない2つの解決策があります。
まず、基盤となるハードウェアプラットフォームをさらに制御できるプラットフォームにこれを移動すると、サーバーの実行中にすべてのファイルのディスクスナップショットを取得できます。たとえばAWSでは、EBSディスクのスナップショットを作成でき、後で別のスナップショットを作成するときにのみ、差分の支払いを行うこともできます。
次に、Ansibleなどの構成管理システムを使用してサーバー全体の設定をスクリプト化することをお勧めします。この意志
ソース管理で構成したすべてを文書化する
バックアップまたはベアメタルからサーバーをテストして再作成し、スクリプトが最新であることを確認できます
新しいオペレーティングシステムでスクリプトを再実行できます。通常はわずかな変更が加えられています。