タイムマシンファイルをあるディスクから別のディスクにコピーするより速い方法はありますか？

タイムマシンのバックアップファイルをすべてBackups.backupdbの下にある別のドライブに移動しようとしています。私は一晩でファイルのコピーを開始しました（b / cコピーの準備にOSXが永遠にかかったことがわかりました...基本的には何時間もファイルを数えていました）。朝、特定のバックアップ（日付のあるフォルダー）のみがコピーされることがわかりました。次に、コピーされなかったものをコピーしようとしました...しかし、OSはそれを許可しませんでした。「バックアップ項目を変更できないため、操作を完了できません」というエラーが表示されました。そのため、新しいドライブ上の不完全なコピーを削除してから、Backups.backupdbフォルダーをもう一度コピーしようと考えています。

かなりイライラします。ターミナルコマンドを使用してこれらのファイルをコピーして、すべてのファイルカウント準備を実行しないようにするより速い方法はありますか？

フォルダー全体をtarでコピーしてからコピーを実行できますが、ファイルのアクセス許可などに干渉しますか？このアプローチの1つのことは、tarのソースボリュームにこれ以上のスペースがないことです。

更新

特にディスクユーティリティの復元機能を使用して、人々が以下に提案する方法のいくつかを試してみましたが、いくつかのエラーメッセージと予期しない結果が得られます（少なくとも私には）。私は2つの方法で復元を試みました。

• [宛先の消去]をオンにした場合：毎回（2回試しました）、復元が完了すると、「復元できません-無効な操作」および「復元できません-無効な引数」というメッセージが表示されます。ただし、宛先ディスクはTMファイルのコピーを取得します。奇妙なことは、コピー先のディスクがコピー元のディスクとまったく同じであるということです。サイズも同じです。宛先ディスクは実際には1 TBですが、復元後、ファインダーから情報を取得すると200 GBと表示されます。しかし、ディスクユーティリティでは、1 TBのパーティションが表示されます！

次に、ディスクを検証/修復しようとしましたが、次の結果が得られました。

    無効なBツリーノードサイズ
    ジャーナリングされたHFS Plusボリュームを確認します。
    無効なBツリーノードサイズ
    ボリュームの修復が完了しました。
    必要に応じて、ボリュームのブートサポートパーティションを更新します。
    エラー：ディスクユーティリティはこのディスクを修復できません。できるだけ多くのファイルをバックアップし、ディスクを再フォーマットして、バックアップしたファイルを復元します。

TMディスクを検証/修復するかどうかさえわからない...

• 「Erase Destination」がチェックされていない場合：復元が開始されず、次のメッセージが表示されます。

    復元できませんでした-操作は許可されていません

通常のコピー（またはrsyncまたはdittoを介したコピー）は、互いにリンクされた2つのディレクトリを変換するため、Time Machineを完全にレプリケートしません（連続したTMバックアップで変更なしで行われます）。

最良の方法は、ディスクユーティリティまたはCarbon Copy Clonerのブロックコピー部分を使用してディスク全体をコピーすることで、おそらくSuperDuperでも同様です。

macOS 10.14で完全な3TB Time Machine暗号化ドライブを新しい8TBドライブに移行すると、あらゆる種類の問題に遭遇しました。ディスクユーティリティで復元を実行しようとすると、「ソースを検証できません」または「操作は許可されていません」というエラーが発生しました。この投稿や他の投稿で他の提案を試してみたところ、「イメージ/ボリューム上のカタログファイルが断片化されすぎています」などのエキサイティングな新しいエラーメッセージを得ることができましたが、コピーはありません。

最後に、ターミナルで働いたもの：

1. ソースドライブのフォーマットに一致するディスクユーティリティで新しいディスクを消去します：MacOS Extended（Journaled、Encrypted）
2. diskutil cs list端末で使用して、古いドライブ上の論理ボリュームの正確なバイトサイズ、新しい論理ボリュームのGUID、および両方のディスク番号を取得しますdisk4。

3. 新しいボリュームのサイズとして、step2の正確なバイトサイズを使用します。私の場合、3TBドライブでは2,999,772,905,472バイトでした：

   sudo diskutil cs resizeVolume $new_lv_guid 2999772905472
   

4. pvhomebrew のコマンドを使用して、ディスクの低レベルブロックコピーを実行します。これはを使用するのとよく似ていddますが、ETAで進行状況メーターを取得する点が異なります。

   diskutil cs list出力からディスク番号を取得する必要があります。注意してください。ここで、誤ってフルバックアップドライブを新しい空のドライブで上書きするのは非常に簡単です。

   sudo sh -c "$(which pv) --buffer-size 50M -s 2999772905472 < /dev/rdisk${source} > /dev/rdisk${target}"
   

   ここで許可が拒否された/操作が許可されていないというエラーが表示された場合は、セキュリティとプライバシーの設定に移動し、Terminal.appのフルディスクアクセスを追加します。

   私にとっては、これには約10時間かかりましたが、一晩実行しましたが、pv少なくとも、ETA付きの進行状況メーターが表示されます。

5. 次に、ボリュームを拡張して、ドライブ上の残りのすべてのスペースを占有します。

   sudo diskutil cs resizeVolume $new_lv_guid 0
   

   約5年のバックアップで、これには約3時間かかりました。その時間のほとんどはmacOS fscking によって費やされました。

これで、より広々とした新しいTime Machineドライブをお楽しみいただけます。古いドライブを転用したり、新しいドライブに何かが起こった場合に備えて安全な場所に格納したりできます。

サイズ変更の手順は重要なようです。それらをスキップすると、10時間のファイルコピーが発生し、3 TBのファイルシステムを含む8 TBのボリュームが生成されましたが、サイズ変更の方法がわかりませんでした。

更新このアプローチの潜在的な欠点の1つは、ビットごとのコピーであるため、古いディスクと新しいディスクで識別子が同じであるということです。古いフルディスクを接続すると、Time Machineは新しいディスクであると判断し、バックアップを試み、新しいバックアップ用のスペースを確保するために古いバックアップの削除を開始します。データを大きなディスクに移動して、古い小さなディスクを消去するための素晴らしいアプローチのようです。

なぜターミナルを使用しないのですか：

cp -RnpP Backups.backupdb

• -R 再帰的
• -n 上書きしない（既存のコピーの残りが以前の試行から残っている場合）
• -p ACL、許可、作成/変更日などを保持します。
• -P ハードリンクを保持し、ハードリンクまたはシンボリックリンクをたどらない。

この答えはそれを速くすることはできませんが、重複排除（ハードリンク）とアクセス許可を維持しながらデータを適切にコピーする方法を見つけました。追加のボーナスとして、これを使用して、アーカイブ用の最終製品の圧縮されたdmgを作成します。

1. ディスクユーティリティを使用して、Backups.backupdbディレクトリよりも大きいディスクイメージを作成します。また、イメージ形式にはスパースバンドルディスクイメージを使用し、パーティションにはハードディスクを使用することをお勧めします。このイメージがマウントされたら、情報を取得し、このボリュームの所有権を無視の選択を解除します。

2. ここでTime Machineをオフにし、ファインダーを使用してBackups.backupdbフォルダーをマウントされたイメージにコピーします。ファインダーは、データをコピーするためのスーパーユーザーの許可を求めます。しばらく飲んだり、何か他のことをしたりします。

3. コピーが終了したら、すべてが正常であることを確認し、イメージをマウント解除します。ディスクユーティリティから[変換]を選択し、スパースバンドルイメージを圧縮イメージに変換します。繰り返しますが、これには時間がかかる場合があります。

Time Machineバックアップのコピーを2つ作成する必要があります。まばらなバンドルバージョンを削除し、dmgを時間のあるアーカイブとして安全な場所に置くことができます。

これで試したことのないことの1つは、dmgからシステムの復元を行うことですが、動作するはずだと思います。私の目標はタイムマシンの増分変更をアーカイブし、ハードリンク構造を維持することでした。

rsyncとcpも試しましたが、xが過去の日付の量であるxのサイズになるハードリンク構造を保持していないようです。この方法はうまく機能しましたが、ブロックコピーソリューションの速度が得られない可能性があります。

Appleには、このための公式チュートリアルがあります。「Time Machine：現在のバックアップドライブから新しいバックアップドライブにバックアップを転送する方法」。

そのページからの大まかな手順：

1. 新しいバックアップドライブの形式を確認します
2. 新しいバックアップドライブに権限を設定します
3. Time Machineを一時的にオフにする
4. バックアップデータを元のドライブから新しいドライブにコピーします
5. 新しいドライブを使用するようにTime Machineを設定します

これは、ページがコピー手順の実行を推奨する方法です。

バックアップデータを元のドライブから新しいドライブにコピーします

1. 新しいFinderウィンドウを開きます。Finderサイドバーで、元のバックアップドライブのアイコンをクリックします。
2. 新しいFinderウィンドウを開きます。Finderサイドバーで、新しいバックアップドライブのアイコンをクリックします。
3. フォルダ「Backups.backupdb」を元のバックアップドライブから新しいバックアップドライブの最上位にドラッグします。
4. 管理者の名前とパスワードを入力し、[OK]をクリックしてコピープロセスを開始します。

バックアップのサイズによっては、バックアップデータのコピーが完了するまでに時間がかかる場合があります。

ディスクユーティリティの+1、コメントには長すぎます：

12.250.329ファイルが評価され、10.408.594ファイルがコピーされました。有効なコピー速度は8,68 MB / sです。

SuperDuperを使用した数年のバックアップで磁気2TBバックアップドライブのクローンを作成するために！今年。

約4日と4分の1のファイルの後でキャンセルしたFinderコピーとは対照的に、これには合計で63時間かかりました（SuperDuperは24時間ごとにクロックをリセットし、最終的に15:04:43を示しました）。

明らかに、磁気ディスクがこれほど長くかかった理由ではなかった。Finderが長時間実行されるバックアップディスクにストールする理由は、特にGitインデックスのような多くの小さなファイルの場合、変更されていないファイル上のカスケードシンボリックリンクの数が非常に多いためです。

rsyncは、このようなものに最適なユーティリティです。私は通常、このようなものに使用します。この場合、-aPフラグを使用できます。-a（「アーカイブ」）の一部は、アクセス許可、ACLなどを保持することでもあると思いますが、よくわかりません。

IIRCには、ソースファイルがコピー先に正常にコピーされた後にソースファイルを削除できる--deleteオプションもあります。ただし、それを使用する場合は注意が必要です。通常は、-deleteオプションを使用せずに完全なミラーリングを行い、-cオプションと--deleteオプションを指定してコマンドを再実行します。-cはチェックサムであるため、ダウンロードしたすべてのファイルをチェックサム経由でソース上のすべてのファイルと照合し、一致する場合はソースを削除します。そうでない場合は、場合によっては再コピーまたはコピーを再開します。

編集：この場合、ハードリンクを保持するために、コメントごとに-Hフラグを使用してください。

ハードドライブでは、1つのドライブから複数のファイルを移動すると、リーダーが前後に移動して恐ろしいクリック音を出し、転送速度を大幅に低下させます。たとえば、USB 2.0の1つのファイルは、2から30 mbps外付けハードドライブ、ただし2つのファイルは11 mbpsで移動します。また、3つのファイルは6 mbpsで移動します。などzipファイルはファイルよりも速く移動します。