スポンサーリンク

Veeam BackupのViBファイルを削除しても大丈夫か?

スポンサーリンク

Veeamでボリュームを外部HDDなどにバックアップしている際,ディスク容量が一杯になってしまい,バックアップが失敗してしまう場合があります。

そのような場合,例えば30日間のバックアップを保持していたとすると,容量を節約するために20日分のバックアップだけ保持しておくことに変更するかもしれません。

ではその際,最も古い10日間分のバックアップデータを,つまり最も古い10個のViBファイルを削除してしまっても良いでしょうか。

答えはNoです。

VeeamのViBファイルは差分ファイルであり,すべてのViBファイルがチェーンとなって,一つの大きなバックアップを構成しています。

そして,バックアップ保持期間を縮小したとしても,その統合作業が行われるのは,次のバックアップジョブが完了した後に行われます。

Mergeのジョブは,バックアップが正常に完了した後に行われるので,容量不足でFailする場合には,Mergeは実行されない。

Mergeのジョブは,バックアップが正常に完了した後に行われるので,容量不足でFailする場合には,Mergeは実行されない。

それで,ひとたび容量不足でバックアップジョブが失敗してしまった場合,これを解消するためには,根本的な策を打たなければなりません。

では,幾つかのシナリオに応じて,対処策を列挙しておきたいと思います。

想定されるケースとしては,次の2つの要素が関係します。

1.Backup Setの数
例えば2つのVMをバックアップしているとすれば,Backup Setは2です。

2.Full Restore Pointの数
Settings内のAdvanced Settingsにて,Active full backupの項目を,Create active full backups periodicallyにチェックしていると,Full Restore Pointが複数作成されます。そうでなければ,Full Restore Pointの数は1です。

Active full backupタブのCreate active full backups periodicallyにチェックしているかどうか

Active full backupタブのCreate active full backups periodicallyにチェックしているかどうか

スポンサーリンク

VeeamのBackup Setが1つでFull Restore Pointが2つ以上ある場合

バックアップ先のフォルダを開き,新しいファイル順にソートします。

そして,一番下の古い.vibファイルから数えていき,最初に.vbkファイルが出てくるところまでが,一つのバックアップチェーンです。

それで,その.vibファイル群と.vbkの一式を削除して,ディスク容量を解放します。

Veeamのバックアップ保持期間の日数を調整し,バックアップのディスク容量内に収まるようにします。

VeeamのBackup Setが2つ以上でFull Restore Pointが1つの場合

1つのBackup Setをフォルダごと他の場所に移動して,容量を開放します。

残ったBackup Setに対するバックアップ保持日数を縮小してから,バックアップジョブを実行します。

すると,バックアップチェーンがシュリンクされます。

退避させていたBackup Setを元の場所に戻します。

VeeamのBackup Setが2つ以上でFull Restore Pointが2つ以上の場合

上述のどちらかの方法をとります。

古いバックアップチェーン一式を削除するか,Backup Setを退避させてシュリンクする方法です。

以上,Veeam Backupでディスクが一杯になってしまった場合ののViBファイルの圧縮方法でした。

ご質問等があれば,コメント欄にどうぞ。

コメント

  1. 匿名 より:

    現在Veeam Agent for Microsoft Windowsの2.0.0.700を使用しています。
    NASにFile level backupの設定をしており、まだバックアップ先のキャパとしては充分な容量があるのですが、一旦バックアップファイルを縮小したいと思いました。

    現在の設定は私が2年ほど前に行い、保持期間180日にしておりました。
    この記事を見て、ファイルを減らしたい場合は純粋にvibファイルを削除してはいけないと知りました。

    例えば保持期間を現在の180日から、10日に変更したい場合、設定画面から10日と入力するとして、次回バックアップ実施時に今日から過去10日分は残るのでしょうか。

    それとも今日をきっかけにして、10日後にこのバックアップの仕組みが初めて完成するという挙動になるのでしょうか。

    何卒宜しくお願い致します。

    • macruby macruby より:

      そのシナリオの場合,次回のバックアップジョブの最後のステップで,古い170日分の差分ファイルを,フルバックアップファイルに統合するというジョブが走ります。

      つまり,170日分の.vibファイルを,.vbkファイルに統合するジョブが走ります。

      ですので,次回のバックアップジョブが完了した際には,10日前までの差分ファイルをもつ,一つの完全なバックアップチェーンができあがっています。それから10日間待つ必要はありません。

      マージする.vibファイルが多ければ,ある程度の時間がかかるとは思いますが,問題なく完了するはずです。
      ご参考になれば幸いです。

      • 匿名 より:

        macruby様
        御回答ありがとうございます。
        本日確認したところ、以前よりvibファイルが減っていたように思います。
        180日なので約半年分存在していたものが、約2か月ほどになっておりました。

        ログを見てみるとバックアップ開始から7時間程経過して、マージに失敗しましたというエラーが上がっておりました。
        2019/06/28 4:19:49 :: Full backup file merge failed Error: Agent: Failed to process method {Transform.Patch}: The specified network name is no longer available.

        恐らくこのマージが成功していれば過去10日分のみに縮小出来たということでしょうか。

        もう少し様子を見てみたいと思います。
        何卒宜しくお願い致します。

        • macruby macruby より:

          そうですね,オペレーション自体には問題は無かったと思います。SMBのコネクションエラーのようですので,様々な原因が考えられますが,まずはもう一度ジョブが走るのを待って,再度マージが走った際にどうなるかを観察するのが良いかと思います。

          • 匿名 より:

            mecruby様

            ご回答ありがとうございます。
            先ほど確認したら無事にマージが完了しており、vibファイルが過去10日分のみになりました。

            差分の保持期間を180日⇒10日に変更したのですが、
            元の使用済み容量が2.1TBで現在が1.7TBで400GB程度しか削減出来ておりませんでした。
            これはこういった仕様なのでしょうか。

          • macruby macruby より:

            無事にマージが成功したようで,良かったですね。
            どの程度削減できるかは,元データのサイズと比較してみないと何とも言えないところですが,元データと,10日分の差分データという観点から見てあまりにも1.7TBというサイズが大きすぎるようでしたら,いったんすべての.vbkと.vibを別のフォルダに移動させたりして,再度バックアップを新規で作り直してみるというのも手だと思います。

  2. 匿名 より:

    mecruby様

    ご回答ありがとうございます。
    削減容量の妥当性は圧縮の構造によりけりかと思いますので、私のような素人が何か口出し出来る領域でも無いですね。
    一旦本件これにて様子見としたいと思います。

    御対応いただきありがとうございました。

    • macruby macruby より:

      ご報告ありがとうございます,同様の疑問をもつ他の方の助けにもなると思います。また何かご不明な点がございましたら,ぜひコメント欄にてお知らせください。