web-dev-qa-db-ja.com

重複+ AmazonS3氷河。バックアップを再開するための「フリーズ解除」の量

[Amazon S3への]重複バックアップを最後に行ってから数か月が経ちましたが、その間に、Amazonバケットにある30日間の自動ルールのおかげで、S3バックアップは「通常の」削減から移動されました。 AmazonGlacierへの冗長ストレージ。

さて、duply <backupname> verify -v9を実行すると、最後に次のように出力がハングアップするのがわかります[これは、Glacierからの各復元に数時間かかるため、一晩実行した後です]：

-------------------------
Chain start time: Sun Dec  1 14:49:39 2013
Chain end time: Fri May  1 20:18:38 2015
Number of contained backup sets: 16
Total number of contained volumes: 1438
 Type of backup set:                            Time:      Num volumes:
                Full         Sun Dec  1 14:49:39 2013               318
         Incremental         Wed Dec 11 13:21:16 2013                 1
         Incremental         Wed Dec 18 19:48:07 2013                15
         Incremental         Tue Dec 31 18:45:25 2013                 4
         Incremental         Sat Jan  4 18:06:42 2014                 9
         Incremental         Sat Feb 15 15:14:59 2014                15
         Incremental         Sat Feb 15 15:43:26 2014                 1
         Incremental         Mon Feb 17 10:18:31 2014                 3
         Incremental         Mon Feb 17 10:24:57 2014                 1
         Incremental         Wed Feb 19 14:35:22 2014                 1
         Incremental         Wed Feb 19 14:38:52 2014                 1
         Incremental         Sun Mar  2 22:37:32 2014               514
         Incremental         Wed Jul  9 20:12:22 2014                26
         Incremental         Sat Dec  6 22:57:27 2014               262
         Incremental         Fri May  1 18:37:57 2015               266
         Incremental         Fri May  1 20:18:38 2015                 1
-------------------------
No orphaned or incomplete backup sets found.
Using temporary directory /tmp/duplicity-Q5My3G-tempdir
Registering (mktemp) temporary file /tmp/duplicity-Q5My3G-tempdir/mktemp-DGtqcn-1
File duplicity-full.20131201T144939Z.vol1.difftar.gpg is in Glacier storage, restoring to S3
Waiting for file duplicity-full.20131201T144939Z.vol1.difftar.gpg to restore from Glacier
File duplicity-full.20131201T144939Z.vol1.difftar.gpg was successfully restored from Glacier
Registering (mktemp) temporary file /tmp/duplicity-Q5My3G-tempdir/mktemp-AQObTq-2
Waiting for file duplicity-inc.20131201T144939Z.to.20131211T132116Z.vol1.difftar.gpg to restore from Glacier
File duplicity-inc.20131201T144939Z.to.20131211T132116Z.vol1.difftar.gpg was successfully restored from Glacier
Registering (mktemp) temporary file /tmp/duplicity-Q5My3G-tempdir/mktemp-U6R9NX-3
File duplicity-inc.20131211T132116Z.to.20131218T194807Z.vol1.difftar.gpg is in Glacier storage, restoring to S3
Waiting for file duplicity-inc.20131211T132116Z.to.20131218T194807Z.vol1.difftar.gpg to restore from Glacier
File duplicity-inc.20131211T132116Z.to.20131218T194807Z.vol1.difftar.gpg was successfully restored from Glacier
Registering (mktemp) temporary file /tmp/duplicity-Q5My3G-tempdir/mktemp-6ZNOgl-4
File duplicity-inc.20131218T194807Z.to.20131231T184525Z.vol1.difftar.gpg is in Glacier storage, restoring to S3
Waiting for file duplicity-inc.20131218T194807Z.to.20131231T184525Z.vol1.difftar.gpg to restore from Glacier

さて、Duplicityを前回中断したところから続行するには、最新のdifftarファイルをGlacierから解凍する必要があると思っていました。しかし、バックアップがインクリメンタルであることを考えると、なぜそれがさらに[以前の] difftarファイルを「フリーズ解除」しているように見えるのかについて私は困惑しています。今のところコマンドをキャンセルしましたが、再試行しても安全かどうかを確認する必要があります。 Duplicityが再開する前に、少数のdifftarファイルのフリーズを解除する必要がある場合は、それで問題ありません。しかし、80 GB以上がバックアップされているため、バックアップアーカイブ全体のフリーズを解除する余裕はありません。

誰かがこれについて何かアイデアを持っていますか？

前回、Duplicityが私のレーダーにありましたが、Glacierのサポートを追加するという話があり、Waiting ... to restore from Glacierメッセージはこれが行われたことを示唆しています。ただし、バックアップファイルは、Duplicity自体を介して明示的にではなく、自動バケットルールによってGlacierに移動されたため、バックアップを再開できるかどうかに関して、これが問題を引き起こしたかどうかはわかりません。

backupawsduplicityamazon-s3
4
stíobhart

最初にincrementalを実行せずにverify更新を実行できると思います。マニュアルページには

重複は、バックアップから復元する場合を除いて、アーカイブファイルへのアクセスを必要としません。

しかし、私のテストに基づくと、verify（少なくとも）は一種の復元としてカウントされます。

1
Dave