Linuxサーバーのバックアップ方法｜rsyncで別サーバーに保存する手順
LinuxサーバーでWebサイトやアプリケーションを運用していると、設定変更の失敗やストレージの故障などに備えて、必要なファイルを別の場所に保存しておくことが重要です。
Linuxでは、rsyncを使うとファイルやディレクトリを別のサーバーへ効率よくコピーできます。SSH経由で転送できるため、ネットワーク越しのバックアップにも利用できます。
ただし、ファイルをコピーしただけで、いつでも復旧できるバックアップが完成するわけではありません。保存先の確認や転送結果の確認に加え、復元できる状態かどうかも考えておく必要があります。
rsyncでLinuxサーバーをバックアップする仕組み
rsyncは、ファイルのコピーや同期に使われるコマンドです。コピー先に同じファイルがある場合、変更状況などを確認して転送量を抑えられるため、定期的なバックアップにも利用できます。
たとえば、Webサーバーのファイルをバックアップ用サーバーへコピーする場合、次のような構成にできます。
- バックアップ元：Webサイトを運用しているLinuxサーバー
- バックアップ先：バックアップファイルを保存する別のLinuxサーバー
- 転送方法：SSHを利用したrsync
- 保存対象：Webサイトのファイルや必要な設定ファイルなど
バックアップ先を別のサーバーにすることで、元のサーバーのストレージに問題が起きた場合にも、コピーしたファイルを別の場所から取り出せます。
ただし、同じサーバー内の別ディレクトリにコピーするだけでは、サーバー本体やストレージ全体の故障に備えられません。また、同期先まで削除や不正変更の影響を受ける構成では、バックアップとして十分でない場合があります。
rsyncを実行する前に確認すること
実際にコマンドを実行する前に、バックアップ元と保存先を整理しておきましょう。
1. バックアップするディレクトリを決める
まず、何を保存する必要があるのかを確認します。
Webサーバーなら、Webサイトのファイルが/var/www/に置かれている構成があります。ただし、実際の保存場所はサーバーの設定によって異なります。
次のコマンドで、対象ディレクトリの内容を確認できます。
ls -lah /var/www/必要なファイルが別のディレクトリにある場合は、その場所も確認してください。設定ファイルやアプリケーションのデータなど、Webサイトのファイル以外にも保存すべきものがあるかを整理しておくと、バックアップ漏れを減らせます。
2. バックアップ先へのSSH接続を確認する
以下は、バックアップ先のホスト名がbackup.example.com、ユーザー名がbackupuserの場合の例です。
ssh backupuser@backup.example.com接続できない場合は、ホスト名、ユーザー名、SSHの設定、接続先のアクセス権限などを確認します。
なお、backup.example.comは説明用の例です。実際には自分の環境に合わせて変更してください。
3. 保存先ディレクトリを用意する
バックアップ先に、保存用のディレクトリを作成します。
ssh backupuser@backup.example.com \
'mkdir -p /srv/backup/web01'この例では、バックアップ先の/srv/backup/web01にファイルを保存します。ディレクトリを作成するユーザーに必要な権限があることも確認してください。
rsyncで別サーバーにバックアップする手順
1. まずはdry-runで転送内容を確認する
いきなり本番のコピーを始めるのではなく、--dry-runを使って実行予定の内容を確認します。
rsync -avhn \
/var/www/ \
backupuser@backup.example.com:/srv/backup/web01/主なオプションの意味は次のとおりです。
| オプション | 意味 |
|---|---|
-a | ディレクトリ構造や属性などを可能な範囲で保持してコピーする |
-v | 処理内容を表示する |
-h | ファイルサイズなどを読みやすい形式で表示する |
-n | 実際の変更を行わず、試行実行する |
-nは--dry-runの短縮形です。この段階では、コピー先にどのようなファイルが転送される予定かを確認できます。
--dry-runは転送の試行実行であり、バックアップの成功を保証するものではありません。実際の転送結果は、コピーを実行した後に確認する必要があります。
2. 問題がなければ実際にコピーする
転送元と転送先のパスが正しいことを確認したら、-nを外して実行します。
rsync -avh \
/var/www/ \
backupuser@backup.example.com:/srv/backup/web01/SSH経由で接続でき、保存先への書き込み権限があれば、対象ディレクトリのファイルが転送されます。
ここで重要なのは、コピー元の/var/www/のように、パスの末尾にスラッシュを付けている点です。この指定では、/var/www/の中身を保存先の/srv/backup/web01/にコピーします。
一方、コピー元を/var/wwwと指定すると、一般的なディレクトリコピーの動作では、保存先にwwwディレクトリ自体が作られる形になります。保存先の構成を意図どおりにするため、末尾のスラッシュを含めてパスを確認してください。
また、rsync -aは、実行ユーザーの権限などによって保持できる属性が変わります。すべての所有者・権限・特殊属性が必ず完全に再現されるわけではありません。
3. コピー結果を確認する
コマンドが終了したら、終了ステータスを確認します。
echo $?直前のコマンドが正常終了していれば、通常は0が表示されます。0以外の場合は、エラーメッセージを確認し、接続・権限・ディスク容量などの問題を調べてください。
続いて、バックアップ先のファイルを確認します。
ssh backupuser@backup.example.com \
'ls -lah /srv/backup/web01/'必要に応じて、コピー元とコピー先のファイル一覧や容量も比較します。
ただし、ファイルが存在することやコマンドが正常終了したことだけでは、アプリケーションを完全に復旧できるとは限りません。重要なデータについては、実際に復元できるかを別途確認することが大切です。
rsyncのバックアップで注意したいポイント
–deleteは安易に追加しない
rsyncには、コピー先にだけ存在するファイルを削除する--deleteオプションがあります。
これは、コピー元とコピー先を同じ状態に保ちたい場合には便利です。しかし、コピー元のパスを間違えたり、対象ディレクトリを誤って指定したりすると、コピー先のファイルが削除されるおそれがあります。
バックアップの最初の設定では、まず--deleteを付けずに動作を確認してください。削除を伴う同期が必要な場合も、事前に--dry-runで削除予定を確認し、保存先が正しいことを確かめてから実行します。
rsyncだけでデータベースのバックアップが完了するわけではない
WebサイトでMySQLなどのデータベースを使っている場合、データベースのファイルを単純にコピーするだけでは、安全に復元できないことがあります。
データベースは、稼働状況や構成に応じたバックアップ手順を選ぶ必要があります。たとえば、論理バックアップを取得する方法や、利用しているデータベース製品が推奨するバックアップ方式を検討します。
Webサイトのファイルとデータベースは、必要に応じて別々の手順でバックアップすると考えておきましょう。
バックアップ先の容量も確認する
バックアップ先の空き容量が不足していると、ファイルの転送に失敗する場合があります。
保存先のサーバーでは、次のコマンドで空き容量を確認できます。
df -hファイル数が多い場合や、大容量のファイルを扱う場合は、保存先の容量だけでなく、バックアップにかかる時間や転送中のエラーも確認してください。
定期的に復元できるか確認する
バックアップは、ファイルを保存して終わりではありません。必要なときに取り出せなければ、障害への備えとして十分とはいえません。
定期的にファイルを確認し、重要なデータについては別のテスト用ディレクトリなどに復元できるかを検証します。本番環境のファイルを上書きしないよう、復元テストの場所と対象を明確にしておくことも重要です。
また、誤削除や不正変更がバックアップ先にも反映される構成では、過去の状態に戻せない場合があります。必要に応じて、世代管理や変更履歴を保持する仕組み、通常の運用ユーザーから簡単には削除できない保管先なども検討しましょう。
rsyncでバックアップする際の確認リスト
実行前後に、次の項目を確認しておくと安心です。
- バックアップ元のディレクトリが正しい
- 保存先のホスト名とディレクトリが正しい
- SSH接続と保存先への書き込み権限を確認した
--dry-runで転送予定の内容を確認した- 実行後の終了ステータスとエラーメッセージを確認した
- 保存先に必要なファイルが存在する
- データベースなど、別途バックアップが必要なデータを整理した
- 必要なファイルを復元できるか確認する手順がある
まとめ
rsyncを使うと、LinuxサーバーのファイルをSSH経由で別のサーバーにコピーできます。変更されたファイルを効率よく転送できるため、ファイルのバックアップや定期的な同期に活用できます。
一方で、コピー元と保存先の指定を間違えたり、--deleteを不用意に使ったりすると、必要なファイルを失う原因になります。まずは--dry-runで内容を確認し、実行後は終了ステータスと保存先のファイルを確認してください。
サーバーの障害に備えるには、バックアップを取得するだけでなく、データベースを含めた保存対象の整理と、実際に復元できることの確認まで行うことが大切です。