Centos 6のバックアップと復元の手順をテストして文書化しようとしています。これが私がやっていることですが、少し明確にする必要がある領域がいくつかあります。 'ネット上のCentOSバックアップ/復元ドキュメントは少しヒットとミスです。
お気に入りのバックアップソフトウェアを使用して、システムを毎日バックアップします。これについては詳しく説明しませんが、あるシステムのバックアップを作成して別のシステムに復元できる適切なバックアップシステムがあるとします。
煙と炎がサーバーの1つを飲み込みます!差し迫った危険に対処した後、あなたは重要なシステムが取り返しのつかないほど損傷していることに気づきます。別のハードウェアに復元する必要があります。
バックアップファイルを確認してください。障害が発生したシステムの/etc/redhat-release
ファイルのバックアップを確認します。これを使用して、障害が発生したシステムが使用していたCentOSのバージョン(パッチレベル)を確認しますか?このバージョンのインストールメディアを入手してください。
インストールメディアを使用して、オペレーティングシステムを交換用ハードウェアに最小限のインストールを行い、システムの最終用途に応じてディスクをパーティション分割します。
最小限のシステムをインストールした後、selinuxを一時的に無効にし、echo ‘0’> /selinux/enforce
iptablesを停止し、service iptables stop
して、バックアップクライアントをインストールします。
バックアップから回復します、除く回復から次のファイル:
/ proc
/sys
/tmp
/dev/ var/lock<-復元から除外しないでください-回答を参照してください/ var/run<-復元から除外しないでください-回答を参照してください
/var/tmp
/etc/fstab
/etc/mdadm.conf
/etc/mtab
/etc/resolv.conf
/etc/Networks
/etc/sysconfig/network *
/etc/sysconfig/kernel
/etc/hosts
/etc/modprobe *
/etc/networkmanager <-IPが復元されないようにするため-回答を参照
/etc/udev
/lib/modules
/ブート
復元が完了したら、再起動してエラーを監視します
ネットワーク構成が正しいことを確認してください。ネットワーク設定を変更するには、system-config-network
を使用する必要がある場合があります。
ApacheやMySQLなどの一部のアプリケーションは、復元後に正しく起動しない場合があります。 復元から/ var/runと/ var/lockを除外しない限り、これは問題にはなりません-回答を参照してください。/var/run
が復元から除外されたため、/var/run/httpd
のようなサブフォルダーは存在せず、アプリケーションはPIDファイルを正しく作成できません。 /var/run/httpd/
や/var/run/mysqld/
などのフォルダーを復元し、適切なアクセス許可を与える必要があります。
是正措置を完了した後、アプリケーションが正しく起動することを確認します。
MySQLデータベースを実行している場合は、作成したフラットファイルバックアップからデータベースを復元しなくても問題ない可能性があります。 mysqlcheck -c -u root –p******** --all-databases
を実行すると、データベースの状態を確認できます。エラーが表示された場合は、mysqlcheck -c -u root –p******** --all-databases --auto-repair
を実行して修復してください。 以下の回答に示されているように、データベースが適切にバックアップされていることを常に確認する必要があります。私は個人的にmysqldumpを使用しています。
yum update
を使用して、システムを最新レベルにパッチします。
再起動してシステムが明確に復旧し、/ var/log/messagesにエラーがないか徹底的にチェックした後、システムの機能をテストして、正しく動作していることを確認します。この場合は、system-config-network
を使用して、IPアドレスを元の障害のあるシステムのアドレスに変更します。
復元から/var/run/*
を除外すると、一部のアプリのPIDを含むために使用されるサブフォルダーは、復元時に作成されません。復元から/var/run/*
を除外する必要が本当にありますか?単にPIDファイルを復元しないためのより良い方法はありますか?
システムが復元されると、「障害のあるシステム」のIPアドレスも復元されました。私はこれが欲しくなかった。 「リカバリから除外」リストからファイルを見逃したに違いありません。それがどこにあるかアイデアはありますか?
更新すると、/sbin/ldconfig: /usr/lib64/libblah.so is not a symbolic link
のようなメッセージがたくさん表示されます。一部のサービスを更新した後にシステムを再起動すると、正しく起動しません。これは、シンボリックリンク自体ではなく、シンボリックリンクが指すファイルを復元するバックアップシステムと関係があるのだろうか。 ldconfigを実行して、文句を言う共有オブジェクトの1つを見ると、共有オブジェクトはシンボリックリンクではなく実際のファイルです。他の誰かがこれを見ましたか?
/var/run
を除くすでにお気づきのとおり、CentOS6システムの完全な復元中に/var/run
を除外すると、インストールされたパッケージによって作成されたディレクトリも除外されるため、問題が発生します。一部のパッケージはそこにもサブディレクトリを作成するため、/var/lock
を除外しても同様の問題が発生する可能性があります。
(systemd
を使用する最近のLinuxディストリビューションでは、そのような問題は発生しない可能性があります。このようなディストリビューションでは、/var/lock
および/var/run
(実際には/run
)がtmpfs
、および必要なサブディレクトリはすべての起動中に作成されますが、CentOS 6ははるかに古く、/var/lock
または/var/run
でのサブディレクトリの自動作成をサポートしていません。)
ただし、CentOS6の/var/run
スクリプトには次のコマンドが含まれているため、適切な復元には実際には/var/lock
と/etc/rc.d/rc.sysinit
を除外する必要はありません。
find /var/lock /var/run ! -type d -exec rm -f {} \;
このコマンドは、システムの起動中に、古いロックファイルまたはpidファイル(またはソケットやシンボリックリンクなどの他のディレクトリ以外のファイル)をすべて削除します。したがって、復元の除外リストから/var/lock
と/var/run
を削除する必要があります。
バックアップを復元するときは、すでに/etc/sysconfig/network*
を除外しています。これは、/etc/sysconfig/network
ファイル(グローバルネットワーク構成)と/etc/sysconfig/network-scripts
ディレクトリ(インターフェイスごとの構成ファイルifcfg-*
)の両方に一致する必要があります。ただし、これらのファイルはinitscripts
パッケージに含まれる 古いスタイルのネットワーク構成スクリプト によってのみ使用され、CentOS 6には別のネットワーク構成システムがあります— NetworkManager 、設定は/etc/NetworkManager
に保存されます。バックアップを復元するときに、そのディレクトリも除外してみてください。
復元後にシンボリックリンクがプレーンファイルに置き換えられた場合は、バックアップ/復元プログラムが正しく構成されていないか、(実際のシンボリックリンクを保存および復元するオプションがない場合)使用したプログラムが適切でないことを意味します。 Linuxシステムのバックアップ/復元の場合。プログラムが確実にシンボリックリンクを含まない特定のデータのみをバックアップおよび復元するために使用される場合にのみ、シンボリックリンクをサポートしないプログラムを回避することができます。予期しない場所にシンボリックリンクが見つかる場合があることに注意してください。たとえば、MySQLデータベースディレクトリでシンボリックリンクが使用される場合があります(データの一部を別のデバイスに保存するため)。したがって、「シンボリックリンクなし」の仮定に依存します。危険かもしれません。
バックアッププログラムが実行中のサーバーからファイルをコピーするだけの場合、バックアップは実際には「クラッシュコンシステント」ではありません。異なるファイル(および同じファイルの異なるブロック)が異なる時間にコピーされるため、実際には一貫したスナップショットが得られないためです。バックアップ内のデータベースの。 (これは、MySQLだけでなく、あらゆる種類のデータベースに適用されます。)
ファイルレベルのバックアップのみを使用してMySQLデータベースをバックアップする方法はいくつかあります。
ファイルレベルのバックアップを開始する前に、mysqldump
を使用してSQLダンプを作成します。データベースディレクトリの代わりにダンプファイルをバックアップします。これは最も移植性の高いバックアップ形式ですが、ダンプと復元の両方が遅い場合があります。
バックアップを開始する前にMySQLサーバーを停止し、ファイルレベルのバックアップを作成してから、MySQLサーバーを再起動します。復元するには、新しいサーバー上のすべてのファイルを復元してから、サーバーを通常どおりに起動します。この種のバックアップは高速ですが、バックアップ中にかなりのダウンタイムが必要になります。
前の方法で必要なMySQLサーバーのダウンタイムを減らすには、サーバーを停止した後にファイルシステムスナップショットを作成し、MySQLサーバーを再起動してからスナップショットをマウントし、ファイルレベルのバックアップを実行してスナップショットを削除します。スナップショット用にボリュームグループに空き領域があるLVMボリュームにファイルシステムを配置する必要があります。
ダウンタイムをさらに短縮するには、説明されているように、サーバーを停止する代わりに、スナップショットを作成する前にFLUSH TABLES WITH READ LOCK
を使用できます ここ ;この場合、スナップショットには、整合性のある状態のMyISAMテーブルと、クラッシュ整合性のある状態のInnoDBテーブルが含まれます(ファイルレベルの復元後にInnoDBリカバリが必要になります)。
MySQLバックアップの詳細については、 このドキュメント をお読みください。
この質問スレッドの除外リストと1つのRackspaceチュートリアルを組み合わせることで、インストールされているCentOSサーバー全体を複製/コピーするために以下の構成を確実に機能させることができました。
私のセットアップはCentOS6.7 + Virtualminです。ただし、これはコントロールパネルがなくてもCentOS6.Xで機能する可能性があります。
私が作成した手順は次のとおりです。
Virtualminを使用していない場合は、Virtualminアイテムを除外する必要がある可能性があります。
リモートサーバーにコピーする除外ファイルリストは次のとおりです。
/boot
/proc
/sys
/tmp
/dev
/var/tmp
/etc/fstab
/etc/mdadm.conf
/etc/mtab
/etc/resolv.conf
/etc/networks
/etc/sysconfig/network*
/etc/sysconfig/kernel
/etc/hosts
/etc/modprobe*
/etc/networkmanager
/etc/udev
/lib/modules
/var/lock
/etc/conf.d/net
/etc/network/interfaces
/etc/sysconfig/hwconf
/etc/sysconfig/ip6tables-config
/etc/hostname
/etc/HOSTNAME
/etc/modules
/net
/etc/rc.conf
/usr/share/nova-agent*
/usr/sbin/nova-agent*
/etc/init.d/nova-agent*
クレジット:
https://support.rackspace.com/how-to/migrating-a-linux-server-from-the-command-line-2/
Linux(CentOSとRed Hatを含む)のイメージスタイルのバックアップを作成する分野で驚くべきことを行った優れたオープンソースプロジェクトReaR(Relax and Recover)があります。特に注目すべきは、ファイルシステムレイアウトをキャプチャし、これをリカバリディスクに組み込んで、ファイルシステムレイアウトの復元を非常にうまく機能させるための優れた方法です。何よりも、それはbashで書かれています(そして起動するために本当によく書かれたbashです!)。
簡単なチュートリアルを書いた以外は、プロジェクトとは関係ありません http://carroll.net/blog/red-hat-bare-metal-backup 。