rsyncは、ファイルやディレクトリを効率的に同期させるための強力なツールです。主に以下の特徴を持っています。
- 差分のみを転送するため、ネットワーク負荷を最小限に抑える
- 圧縮オプションにより、さらに転送速度を向上させることができる
- ローカルおよびリモートでのファイル転送が可能
- 同期やバックアップにおいて非常に柔軟性が高い
基本的なrsyncのコマンド
まずは、基本的なrsyncコマンドの形式を見てみましょう。以下のコマンドは、ローカルPCからリモートサーバーにファイルを転送する基本的な例です。
rsync -av /path/to/local/dir/ user@remote:/path/to/remote/dir/
オプションの説明
-a：アーカイブモード。ディレクトリの再帰的コピー、ファイルの所有権、パーミッション、タイムスタンプなどを保持するため、完全なバックアップに適しています。-v：詳細モード。進行状況やファイル名を表示します。
例
ローカルのディレクトリ/home/user/documents/をリモートサーバーにバックアップする場合、次のようにコマンドを使用します。
rsync -av /home/user/documents/ user@remote:/backup/documents/
これで、リモートサーバーの/backup/documents/ディレクトリに、ローカルのdocumentsディレクトリが完全に同期されます。
実際に試してみる
rsync -av ubuntu@10.0.0.4:/var/www /tmp[root@instance-20220518-2006 tmp]# rsync -av ubuntu@10.0.0.4:/var/www /tmp
The authenticity of host ‘10.0.0.4 (10.0.0.4)’ can’t be established.
ECDSA key fingerprint is SHA256:okV6TespGViKlme5EioFCSZIzoDSHdaaT1KXDK3YF/M.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added ‘10.0.0.4’ (ECDSA) to the list of known hosts.
ubuntu@10.0.0.4: Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.3]
しかし、上のようなエラーが発生しました。
移行元で使用していた秘密鍵を使用しないと駄目らしい。TeraTermのSSH SCP機能を使用してキーを転送します。
応用的な使い方：リモートからのデータ受信
次に、応用的な使い方に進みます。リモートPCからローカルPCにファイルを受信する場合のコマンドです。
rsync -av ubuntu@10.0.0.4:/var/www /tmp
このコマンドは、リモートサーバー10.0.0.4の/var/wwwディレクトリをローカルPCの/tmpディレクトリにコピーします。
エラー対応
もし、上で説明したように、次のような一般的なエラーが発生した場合、秘密鍵の問題である可能性があります。
ubuntu@10.0.0.4: Permission denied (publickey)
この場合、秘密鍵をTeraTermなどのツールを使って転送します。
以下のようにrsyncコマンドを修正します。
rsync -e 'ssh -i /path/to/private-key' -av ubuntu@10.0.0.4:/var/www /tmp
こちらが実際のコマンドです。このキーを使用してファイル転送するコマンドです。
rsync -e 'ssh -i /tmp/ssh-key-2020-12-08.key' -av ubuntu@10.0.0.4:/var/www /tmpうまくファイルを持ってこれました。ただし一部のファイルを転送できないエラーが発生しました。
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1663) [generator=3.1.3]
一部のファイルが転送できないエラー (rsync error: code 23)
rsyncコマンドを使ってファイルを転送している際、以下のエラーが発生する場合があります。
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1663) [generator=3.1.3]
このエラーは、いくつかの理由で一部のファイルが正しく転送されなかったことを示しています。主な原因として、以下のようなものがあります。
1. パーミッションの問題
ファイルやディレクトリのパーミッションが適切でない場合、rsyncはそれらを転送できないことがあります。例えば、所有者がrootであったり、読み取り権限がない場合にこのエラーが発生することがあります。
対処法: 移行元と移行先のパーミッションを確認し、chmodコマンドを使って適切な権限を設定します。
sudo chmod -R 755 /path/to/directory
2. シンボリックリンクの問題
シンボリックリンクを持つファイルやディレクトリを転送しようとすると、そのリンク先のファイルが見つからない場合にエラーが発生します。
対処法: シンボリックリンクを無視するか、正しくリンク先を転送するオプションを使用します。例えば、-Lオプションを使ってリンク先を実ファイルとして転送できます。
rsync -avL /path/to/source/ user@remote:/path/to/destination/
3. ディスク容量の不足
移行先のディスク容量が不足している場合も、ファイルの転送が途中で止まることがあります。
対処法: 移行先のディスク使用量を確認し、必要に応じて不要なファイルを削除して容量を確保します。
df -h
4. 特定のファイルの特殊な属性
rsyncはファイルの特殊な属性（例: xattrやACL）を転送しようとする場合に問題が発生することがあります。このようなファイル属性が原因で、エラーが発生する場合もあります。
対処法: ファイル属性の転送を無効にするオプション--no-xattrsを追加して再試行します。
rsync -av --no-xattrs /path/to/source/ user@remote:/path/to/destination/
これでも解決できなかったり、ディレクトリやファイルの数が多くて困難でした。そこで以下の対策を取りました。
ここでは、ディレクトリやファイルの数が多すぎて一つずつの対処が難しい場合の手法として、ファイルを圧縮して転送する方法を提案します。まず、なぜこの方法が有効なのかを説明します。
なぜ圧縮が有効か？
ファイルが多く、シンボリックリンクやパーミッションなどの問題で一つずつ解決するのが難しい場合、すべてのファイルを一つのアーカイブにまとめることで、これらの複雑な要素を一時的に無視し、単一のファイルとして転送することができます。これにより、複数の問題を回避して効率的に転送できるというメリットがあります。
圧縮方法の説明
次のようにtarコマンドを使用して、ディレクトリ全体を一つのファイルに圧縮します。圧縮することで、ネットワーク転送も高速化されることがあり、特に大規模なディレクトリ構造を扱う場合に有効です。
tar -cvf bk.tar /path/to/directory
このコマンドは、指定したディレクトリ（/path/to/directory）をbk.tarというアーカイブファイルに圧縮します。
移行元で圧縮してから転送
次に、圧縮したファイルを移行先に転送します。これにより、ディレクトリやファイルが個別に扱われず、全体が一つのファイルとして扱われるため、エラーの発生を抑えられます。
rsync -e 'ssh -i /tmp/ssh-key-2020-12-08.key' -av /path/to/bk.tar user@remote:/path/to/destination
圧縮後の処理
移行先でアーカイブを解凍し、ファイルを元の状態に戻します。これにより、ファイルの整合性を維持しつつ、移行が完了します。
tar -xvf /path/to/bk.tar -C /path/to/extract/directory
実際に入力したコマンド
tar -cvf bk.tar minokamo.tokyo上記のコマンドの意味ですが、minokamo.tokyoというディレクトリを一つのファイルに圧縮してから転送する方法について実践したので説明します。圧縮することで、複数のファイルやサブディレクトリを1つのファイルにまとめることができ、転送が簡単かつ効率的になります。
圧縮方法：tarコマンドの使用
まず、tarコマンドを使ってminokamo.tokyoディレクトリ全体をアーカイブ（圧縮）します。以下のコマンドを使用します。
tar -cvf bk.tar minokamo.tokyo
コマンドの詳細
tar：ファイルをアーカイブするためのツール。-c：新しいアーカイブを作成（create）。-v：進行状況を表示（verbose）。-f：アーカイブファイルの名前を指定（この場合はbk.tar）。minokamo.tokyo：圧縮するディレクトリの名前。
このコマンドを実行することで、minokamo.tokyoディレクトリ全体がbk.tarという1つのアーカイブファイルにまとめられます。このファイルには、minokamo.tokyoディレクトリの中にあるすべてのファイルとサブディレクトリが含まれています。
なぜ圧縮するのか？
- 効率的な転送：
rsyncで多数のファイルを一つ一つ転送するのではなく、すべてを一つのファイルにまとめることで、転送がスムーズになり、エラーが発生しにくくなります。 - ファイルの構造保持：圧縮したアーカイブファイルは、ディレクトリ構造やファイルの権限、タイムスタンプなどをそのまま保持するため、移行先で解凍したときにも元の状態が維持されます。
圧縮したファイル（bk.tar）を移行先のPCで取り寄せます。
rsync -e 'ssh -i /tmp/ssh-key-2020-12-08.key' -av ubuntu@10.0.0.4:/var/www/bk.tar /tmpもし、パーミッションのエラーがでたらキーに適切なものを付与しておきます。このエラーはrootでログインすると出ませんでした。
sudo chmod 600 ssh-key-2020-12-08.key以下は、上の対策をとらないために発生したエラー内容です。
[opc@instance-20220518-2006 tmp]$ rsync -e ‘ssh -i /tmp/ssh-key-2020-12-08.key’ -av ubuntu@10.0.0.4:/var/www/bk.tar /tmp
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
Permissions 0644 for ‘/tmp/ssh-key-2020-12-08.key’ are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key “/tmp/ssh-key-2020-12-08.key”: bad permissions
ubuntu@10.0.0.4: Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.3]
一般的な記事にすると以下のようなかんじでしょうか。
圧縮ファイルの転送とパーミッションエラーの対処法
圧縮したファイルを移行先のPCに転送する場合、以下のようなrsyncコマンドを使用します。この方法により、個別のファイルをまとめて効率よく転送できます。
rsync -e 'ssh -i /tmp/ssh-key-2020-12-08.key' -av ubuntu@10.0.0.4:/var/www/bk.tar /tmp
このコマンドは、リモートサーバー10.0.0.4上の/var/www/bk.tarという圧縮ファイルを、ローカルPCの/tmpディレクトリに転送するものです。
パーミッションエラーの対処
ただし、転送時に次のようなパーミッションエラーが発生する場合があります。
WARNING: UNPROTECTED PRIVATE KEY FILE! @
Permissions 0644 for ‘/tmp/ssh-key-2020-12-08.key’ are too open.
This private key will be ignored.
Load key “/tmp/ssh-key-2020-12-08.key”: bad permissions
このエラーは、秘密鍵のパーミッションが適切でないことを示しています。SSHでは、秘密鍵の権限が他のユーザーから見えないように制限されている必要があります。0644のように広すぎる権限だと、秘密鍵が無視され、接続できなくなります。
解決方法
この場合、秘密鍵のパーミッションを600に設定することで、他のユーザーがファイルにアクセスできないようにします。次のコマンドでパーミッションを修正します。
sudo chmod 600 /tmp/ssh-key-2020-12-08.key
chmod 600コマンドは、ファイルのオーナーにだけ読み書き権限を付与し、他のユーザーには一切のアクセスを許可しません。これで、SSH接続が適切に行えるようになります。
エラーが発生する場合
それでもrsyncがうまく動作しない場合、rsyncが途中で接続を切断してしまうことがあります。以下は、エラーメッセージの一例です。
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.3]
この場合、次の点を確認してみてましょう。
- 秘密鍵が正しいものであるか
- サーバーのSSH設定に問題がないか
- パーミッション設定が正しく行われているか
おまけ記事
WordPressデータベースのバックアップと復元
WordPressを移行する際、データベースのバックアップも重要な作業の一つです。WordPressのすべての投稿、ユーザー情報、設定などはデータベースに保存されているため、移行先でこれらの情報を復元する必要があります。
ステップ 1: 移行元のデータベースをバックアップする
まず、移行元のサーバーからデータベースのバックアップを作成します。これを行うには、次のコマンドを使います。
mysql -u root -p
このコマンドを実行すると、MySQLの管理者ユーザーとしてログインするためのパスワードを入力するよう求められます。次に、現在のデータベースを一覧表示して、どのデータベースをバックアップするか確認します。
show databases;
exit
バックアップするデータベースの名前が確認できたら、mysqldumpコマンドを使って、データベースをファイルにエクスポートします。ここでは、my_dbというデータベースを例にしています。
mysqldump -u root my_db -p > /tmp/bk.sql
このコマンドは、my_dbデータベースを/tmp/bk.sqlというファイルにバックアップします。
ステップ 2: データベースのバックアップファイルを移行先に転送
次に、バックアップしたデータベースファイルを移行先のサーバーに転送します。rsyncコマンドを使うと、効率的にファイルを転送することができます。
rsync -e 'ssh -i /tmp/ssh-key-2020-12-08.key' -av ubuntu@10.0.0.4:/tmp/bk.sql /tmp
このコマンドは、リモートサーバー（10.0.0.4）にある/tmp/bk.sqlをローカルの/tmpディレクトリに転送します。
ステップ 3: 移行先でデータベースを作成
移行先のサーバーにバックアップファイルを転送したら、次はそのファイルをインポートするための空のデータベースを作成します。
mysql -u root -p
create database my_db;
exit
この手順で、my_dbという新しいデータベースを作成しました。ここに、先ほどのバックアップをインポートします。
ステップ 4: データベースをインポートする
次に、移行元から持ってきたデータベースファイルを新しく作成したデータベースにインポートします。
mysql -u root -p my_db < /tmp/bk.sql
このコマンドは、/tmp/bk.sqlに保存されたデータベースのバックアップを、my_dbに復元します。
ステップ 5: 圧縮したファイルの展開と配置
データベースの復元が完了したら、次はコンテンツファイルの移行を行います。コンテンツの以降の例は上記で説明したので参考にしてください。移行先の環境に合わせて、DockerやLAMP環境を使ってWebサーバーとPHPの設定を済ませ、WordPressの移行が完了します。
実はほかにも便利なツールがあるので紹介します。それはrcloneです。これについて説明します。rsyncとrcloneの比較をしながら解説します。
rsyncのメリットとデメリット
メリット
- 高速で効率的なデータ転送: 差分転送を行うため、既に存在するファイルは無視され、変更や新規ファイルのみが転送されます。
- ローカルとリモート両方で使用可能: ローカル間のファイル同期や、リモートサーバーとの同期が可能です。
- 詳細なオプション: パーミッション、タイムスタンプ、シンボリックリンクの保持など、ファイルのメタデータも正確に同期できます。
- SSHを通じたセキュアな通信: SSHを使用して、安全にデータ転送が行えます。
デメリット
- クラウドストレージとの統合が限定的: rsyncは主にサーバー間のデータ転送を想定しており、Google DriveやDropboxのようなクラウドサービスと直接統合することが難しい。
- オプションが多すぎて複雑: 初心者にとっては、rsyncの多くのオプションや設定が少し難しいことがあります。
rcloneのメリットとデメリット
メリット
- クラウドストレージとの互換性: rcloneは多くのクラウドストレージ（Google Drive、Dropbox、Amazon S3など）に対応しており、クラウド間やローカルとの同期が非常に簡単です。
- 暗号化サポート: rcloneはデータの暗号化を簡単に行えるため、クラウドストレージにデータをアップロードする際のセキュリティを確保できます。
- 豊富な機能: 単なるファイル転送や同期だけでなく、リストア、バックアップ、チェックサムの確認、帯域制限など、追加の機能も豊富です。
- クロスプラットフォーム対応: Windows、Linux、macOSで簡単に利用できるため、幅広い環境で使いやすいです。
デメリット
- ローカル転送に最適化されていない: rsyncと比べて、ローカル間での大量データ転送にはあまり向いていないことがあります。
- SSHなどのセキュアな転送はオプションが限定的: rcloneはクラウド向けに最適化されているため、SSHを使った細かい設定には不向きな場合があります。
他の方法
- scp（Secure Copy）: ssh経由で簡単にファイルをコピーするためのツールですが、差分転送や同期機能はないため、rsyncやrcloneほどの効率性はありません。
- Cloud Sync Tools: AWS S3やGoogle Cloud Storageの公式ツールも存在し、特定のクラウドストレージに対しては最適化されていますが、複数のサービスを横断した使い方にはrcloneの方が優れています。
この記事内容ではrsyncの方が適していると考えられます。
理由：
- 基本的なファイル同期や転送がメインである場合、rsyncはそのシンプルさと効率性が際立ちます。記事ではWordPressのデータベース移行やサーバー間のファイル転送について説明していますが、これらの用途ではrsyncの差分転送やSSH接続が非常に有効です。
- ローカル環境とリモート環境の間でファイルを同期する場合、rsyncは非常に信頼性が高く、シンプルなコマンドで実行できます。特にサーバー管理やバックアップに強みを持つrsyncは、初心者がWordPressの移行作業を行う際に便利です。
- SSHを使ったセキュアなデータ転送は、WordPressのような重要なデータを扱うときに必要です。rsyncはSSH経由の転送に対応しているため、セキュリティ面でも適しています。
rcloneが適するケース：
もし記事の内容にクラウドストレージの移行やバックアップ（例えばGoogle DriveやAmazon S3など）が含まれている場合、rcloneの方が便利です。しかし、今回の内容がサーバー間の移行やファイル同期に焦点を当てているので、rsyncの方が初心者には理解しやすく、適しているでしょう。
結論として、現在の記事内容で説明しているファイル転送やバックアップのシナリオでは、rsyncが最も適しているツールだと思います。
