Windows Serverの自動増分バックアップは、複数のバックアップディスクで「うまく機能」しますか？
Windows Server 2008 R2以降（私が知る限り、サーバー2019まで）、Windows Serverバックアップは 完全および増分バックアップの自動管理 を実行します。
完全バックアップと増分バックアップの自動管理。完全バックアップと増分バックアップを管理する必要がなくなりました。代わりに、Windows Serverバックアップは、既定では、完全バックアップのように動作する増分バックアップを作成します。単一のバックアップから任意のアイテムを回復できますが、バックアップは増分バックアップに必要なスペースのみを占有します。さらに、Windows Serverバックアップでは、古いバックアップを定期的に削除して新しいバックアップ用のディスク領域を解放するユーザーの介入は必要ありません。古いバックアップは自動的に削除されます。
これはいい機能のようです。
ただし、2つのバックアップディスクを使用します。1つは毎日のバックアップ用に常にサーバーに接続され、もう1つは常にオフサイトのストレージにあります。毎週、これらのディスクを交換して、常に1週間前のオフサイトサーバーバックアップがあることを確認します。
これらの増分バックアップは、代替ディスクでどのように機能しますか？
明らかに、これで問題ありません（オプション1）：
Day 1: Full backup on Disk A.
Day 2: Incremental backup (w.r.t. Day 1 backup) on Disk A.
Day 3: Incremental backup (w.r.t. Day 1+2 backup) on Disk A.
...
Day 8: Full backup on Disk B.
Day 9: Incremental backup (w.r.t. Day 8 backup) on Disk B.
Day 10: Incremental backup (w.r.t. Day 8+9 backup) on Disk B.
...
Day 15: Incremental backup (w.r.t. Day 1-7 backup) on Disk A.
Day 16: Incremental backup (w.r.t. Day 1-7+15 backup) on Disk A.
しかし、これはではなくうまくいくでしょう（オプション2）：
Day 1: Full backup on Disk A.
Day 2: Incremental backup (w.r.t. Day 1 backup) on Disk A.
Day 3: Incremental backup (w.r.t. Day 1-2 backup) on Disk A.
...
Day 8: Incremental backup (w.r.t. Day 1-7 backup) on Disk B.
Day 9: Incremental backup (w.r.t. Day 1-8 backup) on Disk B.
Day 10: Incremental backup (w.r.t. Day 1-9 backup) on Disk B.
...
Day 15: Incremental backup (w.r.t. Day 1-14 backup) on Disk A.
Day 16: Incremental backup (w.r.t. Day 1-15 backup) on Disk A.
復元するには両方のディスクが必要になるため（したがって、2つのディスクを使用する目的を無効にします）。
Windows Serverバックアップはオプション1またはオプション2を使用しますか？そして、これは文書化されましたか？
（明確にするため：質問は太字の前の段落です。「バックアップセットに2番目のディスクを追加する方法」ではなく、「増分バックアップの一般的なしくみ」でもありません。）
Windows Serverの自動増分バックアップは、複数のバックアップディスクで「うまく機能」しますか？
私の意見では、はい。
以下は、私が私の回答の根拠とする議論であり、追加の議論を可能にします。 Windowsバックアップが特定の条件下でどのように動作するかについては、まだよくわからないことがいくつかあり、人々は私を明確化または修正したいと思うかもしれません。それでも、ここで言及する価値があると思います。
Windows Serverバックアップはオプション1またはオプション2を使用しますか？そして、これは文書化されましたか？
まず第一に、一般的に私はあなたに同意し、wbadmin/wbengineがオプション1を実装していることを確信していますが、Microsoftからもこれを証明する決定的な声明はありません。さらに、これはWindows Serverだけに関連するものではなく、Windowsの非サーバーエディションでも同じように機能することもある程度確信しています。実際、私はWindows 7がすでにイメージベースのバックアップを作成しているので、3つの異なるUSBディスクを使用して前述のセットアップを使用しています。 1つのディスクはオフサイトで、2つは1週間以内に定期的に交換されます。
私が見るのは、USBディスクに含まれるVHD（X）ファイルが常に更新され、バックアップにかかる時間と転送されるファイルは、実際にバックアップターゲットとして使用されているUSBディスクが変更されてからどのファイルが変更されたかによって異なります。最後に使用されました。これはドキュメントで言及されている増分部分であり、バックアップの違いのみですが、それらの違いは常にVHD（X）の既存のファイルに書き込まれます。
Windowsイメージバックアップは、それ自体ではバックアップの増分履歴を管理しません。常に、現在使用されているVHD（X）の既存のファイルをバックアップターゲットとして上書きします。したがって、現在利用可能なVHD（X）から復元するために必要な増分履歴はありません。 NTFSフォーマットのUSBディスクの場合、履歴は ボリュームシャドウコピー を使用して実装されます。新しいバックアップを実行する前に、シャドウコピーがバックアップターゲットに作成されます。その後、wbengine VHD（X）を開き、必要に応じてその中のファイルを置き換えます。ファイルの置換はインプレースで行われ、BLOCK-BY-BLOCK、wbengineは実際に変更されたソースファイルを読み取り、読み取ったブロックをバックアップターゲット内の同じブロックと比較し、変更があった場合にのみ上書きします。バックアップターゲットにはシャドウコピーがあるため、VSSは最終的にVHD（X）の実際に変更されたブロックである変更されたブロックを認識し、上書きする前にコピーします。したがって、バックアップターゲットのすべてのシャドウコピーには、以前にバックアップされたシステムの完全に機能するVHD（X）が常に含まれており、これらのシャドウコピーは最終的に増分履歴を作成します。すべてのシャドウコピーには完全に機能するVHD（X）が含まれているため、追加の増分データは必要ありませんが、スナップショット、VHD（X）をそのスナップショット内にマウントし、必要に応じて復元できます。 VSSは、関連するブロックの収集の詳細を処理します。
以下は私がよくわからない点です：
Windowsイメージバックアップはどのファイルをバックアップするかをどのように決定しますか？
Windows/NTFSは各ボリュームの 変更ジャーナル を管理し、どのファイルが変更されたか、どのように変更されたかを追跡します。これらはデフォルトですべてのNTFSボリュームの一部であるため、VHD（X）で使用できます同様にバックアップターゲットの。私の理解から、wbengineは、これらのジャーナルを比較するだけで、バックアップが必要なファイルを認識します。これらの変更ジャーナルはボリューム固有のファイルIDにバインドされており、これらのIDはバックアップターゲットでまったく同じであるため、これにより、ファイルのアーカイブビットなどを気にすることなく、さまざまなバックアップターゲットを簡単にサポートできます。
C:\>fsutil file queryfileid "C:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin\perlapp.exe"
Datei-ID: 0x000000000000000000080000000ea5f1
C:\>fsutil file queryfileid "D:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin\perlapp.exe"
Datei-ID: 0x000000000000000000080000000ea5f1
上記の例では、C:\は現在のシステムボリュームであり、D:\は2つの使用可能なバックアップターゲットのうちの1つにマウントされた最後のバックアップです。ファイルサイズ、タイムスタンプなどもすべて同じです：
C:\>dir /A "C:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin\perlapp.exe"
Datenträger in Laufwerk C: ist System
Volumeseriennummer: 266B-2863
Verzeichnis von C:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin
03.02.2016 17:08 560.640 perlapp.exe
1 Datei(en), 560.640 Bytes
0 Verzeichnis(se), 1.337.040.216.064 Bytes frei
C:\>dir /A "D:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin\perlapp.exe"
Datenträger in Laufwerk D: ist System
Volumeseriennummer: 266B-2863
Verzeichnis von D:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin
03.02.2016 17:08 560.640 perlapp.exe
1 Datei(en), 560.640 Bytes
0 Verzeichnis(se), 1.281.302.233.088 Bytes frei
このアプローチを使用することにより、現在のジャーナルとイメージ内のファイルに共通の何かがあり、それらが私のエントリIDである限り、バックアップはどの古いファイルをバックアップする必要があるかをいつでも決定できます理解。このような共有IDがない場合、生産性の高いI/Oが多すぎてバックアップが古すぎるため、wbengineは増分バックアップではなく単に完全バックアップを実行します。
これらのジャーナルを使用すると、ファイルのツリー全体を反復処理する必要がないため、バックアップするファイルをすばやく知ることができます。これが実際に実際に確認されていることです。バックアップは、バックアップするファイルをすぐに認識し、ファイルツリーを繰り返す代わりにそれらの処理を開始するようです。
Windows Server 2008 R2のバックアップターゲットとしてのネットワーク共有の場合の動作。
ネットワーク共有にバックアップする場合、wbengineの機能は使用するWindowsのバージョンによって異なるようですが、一般的に、以前に説明したアプローチでは、バックアップ内のバックアップボリュームごとに常に1つのVHD（X）しかありませんターゲットも保持しているようです。主な違いは、既存のVHD（X）ファイルを上書きするか、削除して再作成するか、またはUSBディスクの場合と同様に、ファイルを開いてその場で変更することによって、どのように達成されるかです。
いくつかのドキュメントや他の人々がそのトピックに言っていることは次のとおりです：
バックアップをリモート共有フォルダーに保存した場合、同じフォルダーを使用して同じコンピューターを再度バックアップすると、そのバックアップは上書きされます。[...]
ネットワーク共有にバックアップしている場合は、前回の完全バックアップを上書きするたびに完全バックアップが実行されます（VSSが利用できないため）。この場合、バックアップポリシーはまったくなく、単にシステムのリモートシャドウ/コピーを維持しているだけです。
https://lennox-it.uk/a-complete-guide-to-wbadmin-windows-backups
Das kommt darauf an aufは、Medium du sicherstをウェルチします。 Wenn auf Festplatten ect。 gesichert wird、dann wird immer inkrementell gesichert。 Wird auf ein Share gesichert、dann ist es immer ein Vollbackup、wobei das letzte Backupüberschriebenwird。
https://administrator.de/forum/verständnisfragen-windows-server-backup-2012-294395.html
Windows 2008 R2を使用した私自身のテストを見ると、「上書き」は少し誤解を招くように思われます。これは、イメージの名前だけでなく、そのiノードも変更されるため、本当に新しいファイルが作成されるためです。
root@[...]:~# ls -Lisa "/volume1/[...]/WindowsImageBackup/[...]/Backup 2019-11-01 190024"
total 247604492
435 0 drwx------+ 1 [...] users 2582 Nov 2 09:12 .
430 0 drwx------+ 1 [...] users 108 Nov 1 19:58 ..
8200 214832596 -rwx------+ 1 [...] users 220521977856 Nov 1 21:33 3e4779f7-b3e1-11e0-b58f-001999a28c91.vhd
8199 32764536 -rwx------+ 1 [...] users 42484091904 Nov 1 20:12 5d3e4b2f-b386-11e0-ac00-806e6f6e6963.vhd
8214 4 -rwx------+ 1 [...] users 1078 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
8216 12 -rwx------+ 1 [...] users 11940 Nov 1 21:34 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Components.xml
8213 8 -rwx------+ 1 [...] users 5500 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_RegistryExcludes.xml
8203 4 -rwx------+ 1 [...] users 3138 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer0bada1de-01a9-4625-8278-69e735f39dd2.xml
8210 4 -rwx------+ 1 [...] users 1934 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer2a40fd15-dfca-4aa8-a654-1f8c654603f6.xml
8208 4 -rwx------+ 1 [...] users 3414 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
8207 4 -rwx------+ 1 [...] users 1488 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
8212 4 -rwx------+ 1 [...] users 1630 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer59b1f0cf-90ef-465f-9609-6ca8b2938366.xml
8202 4 -rwx------+ 1 [...] users 1628 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer75dfb225-e2e4-4d39-9ac9-ffaff65ddf06.xml
8211 4 -rwx------+ 1 [...] users 950 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writera65faa63-5ea8-4ebc-9dbd-a0c4db26912a.xml
8209 4 -rwx------+ 1 [...] users 1484 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
8206 4 -rwx------+ 1 [...] users 3844 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
8205 8 -rwx------+ 1 [...] users 4288 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
8201 4 -rwx------+ 1 [...] users 1746 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writerd61d61c8-d73a-4eee-8cdd-f6f9786b7124.xml
8204 7284 -rwx------+ 1 [...] users 7455796 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writere8132975-6f93-4464-a53e-1050253ae220.xml
8215 4 -rwx------+ 1 [...] users 1098 Nov 1 21:33 BackupSpecs.xml
root@[...]:~# ls -Lisa "/volume1/[...]/WindowsImageBackup/[...]/Backup 2019-11-02 190054"
total 247603788
435 0 drwx------+ 1 [...] users 2582 Nov 2 21:51 .
430 0 drwx------+ 1 [...] users 108 Nov 2 19:59 ..
8247 4 -rwx------+ 1 [...] users 1078 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
8249 12 -rwx------+ 1 [...] users 11940 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Components.xml
8246 8 -rwx------+ 1 [...] users 5500 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_RegistryExcludes.xml
8236 4 -rwx------+ 1 [...] users 3138 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer0bada1de-01a9-4625-8278-69e735f39dd2.xml
8242 4 -rwx------+ 1 [...] users 1934 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer2a40fd15-dfca-4aa8-a654-1f8c654603f6.xml
8239 4 -rwx------+ 1 [...] users 3414 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
8243 4 -rwx------+ 1 [...] users 1488 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
8241 4 -rwx------+ 1 [...] users 1630 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer59b1f0cf-90ef-465f-9609-6ca8b2938366.xml
8235 4 -rwx------+ 1 [...] users 1628 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer75dfb225-e2e4-4d39-9ac9-ffaff65ddf06.xml
8244 4 -rwx------+ 1 [...] users 950 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writera65faa63-5ea8-4ebc-9dbd-a0c4db26912a.xml
8245 4 -rwx------+ 1 [...] users 1484 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
8240 4 -rwx------+ 1 [...] users 3844 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
8238 8 -rwx------+ 1 [...] users 4288 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
8234 4 -rwx------+ 1 [...] users 1746 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writerd61d61c8-d73a-4eee-8cdd-f6f9786b7124.xml
8237 7284 -rwx------+ 1 [...] users 7455796 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writere8132975-6f93-4464-a53e-1050253ae220.xml
8233 214832596 -rwx------+ 1 [...] users 220521977856 Nov 2 21:51 3e4779f7-b3e1-11e0-b58f-001999a28c91.vhd
8232 32763832 -rwx------+ 1 [...] users 42481994240 Nov 2 20:11 5d3e4b2f-b386-11e0-ac00-806e6f6e6963.vhd
8248 4 -rwx------+ 1 [...] users 1098 Nov 2 21:51 BackupSpecs.xml
これは、画像が名前とファイルID（/ inodes）を保持し、ほとんどのXMLファイルのみが新しいUUIDを取得するUSBディスクに表示されるものとは異なります。 USBディスクでは、VHD（X）の親ディレクトリも変更されますが、これは単なる名前の変更であり、したがって子ファイルにはまったく影響しません。テスト中のある時点で、wbengineがVHDファイルの名前を保持することに決めましたが、そのiノードは常に変更されていました。ただし、新しいコマンドラインを使用して呼び出さなかったが、その後は単に次のようにした。
8260 32767464 -rwx------+ 1 [...] users 42481994240 Nov 3 12:47 5d3e4b2f-b386-11e0-ac00-806e6f6e6963.vhd
8266 32764416 -rwx------+ 1 [...] users 42481994240 Nov 3 13:18 5d3e4b2f-b386-11e0-ac00-806e6f6e6963.vhd
共有を使用する場合に、なぜこのように実装したのかわかりません。基本的なBTRFSスナップショット。しかし、それは私が見ているものとまったく同じです。すべてのスナップショットmy NASは、これらのバックアップを保存するフォルダーに対して作成されます。 wbengineのファイルサイズとランタイムの長さ。すべてのバックアップにかかる時間はほぼ同じですが、バックアップされたソースのファイルはあまり変化しません。
Windows Server 2012+のバックアップターゲットとしてのネットワーク共有の場合の動作。
新しいバージョンのWindowsでは状況が少し異なるようです。私の顧客の1人がwbadminおよびWindows Server 2012で問題に遭遇し、プロセスモニターを使用してそれらをデバッグしているときに、既存のVHDXファイルは削除および再作成されずに保持されました。私は今すぐWindows Server 2019でこれを再度テストしましたが、wbadminを複数回呼び出すとバックアップが成功し、VHDXファイルのiノードを同じに保ちました：
root@[...]:~# ls -Lisa "/volume1/[...]/Backup 2019-11-02 200024"
total 549063256
271 0 d---------+ 1 user group 594 Nov 2 20:58 .
266 0 d---------+ 1 user group 108 Nov 2 20:58 ..
273 507813736 ----------+ 1 user group 520061190144 Nov 2 22:02 165c4b13-8376-4c55-9643-a8c1b2c17d6b.vhdx
3814 4 ----------+ 1 user group 776 Nov 1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
3816 440 ----------+ 1 user group 450488 Nov 1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_Components.xml
3813 8 ----------+ 1 user group 6212 Nov 1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_RegistryExcludes.xml
3815 4 ----------+ 1 user group 1192 Nov 1 22:47 BackupSpecs.xml
272 41249064 ----------+ 1 user group 42289070080 Nov 2 22:03 f7650533-11ca-4db4-80f5-2db42f7b900a.vhdx
root@[...]:~# ls -Lisa "/volume1/[...]/Backup 2019-11-03 132201"
total 549318872
271 0 d---------+ 1 user group 594 Nov 2 20:58 .
266 0 d---------+ 1 user group 108 Nov 3 14:19 ..
273 507813736 ----------+ 1 user group 520061190144 Nov 3 14:19 165c4b13-8376-4c55-9643-a8c1b2c17d6b.vhdx
3814 4 ----------+ 1 user group 776 Nov 1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
3816 440 ----------+ 1 user group 450488 Nov 1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_Components.xml
3813 8 ----------+ 1 user group 6212 Nov 1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_RegistryExcludes.xml
3815 4 ----------+ 1 user group 1192 Nov 1 22:47 BackupSpecs.xml
272 41504680 ----------+ 1 user group 42289070080 Nov 3 14:21 f7650533-11ca-4db4-80f5-2db42f7b900a.vhdx
root@[...]:~# ls -Lisa "/volume1/[...]/Backup 2019-11-03 133308"
total 41262660
271 0 d---------+ 1 user group 2504 Nov 3 14:44 .
266 0 d---------+ 1 user group 108 Nov 3 14:30 ..
3851 4 ----------+ 1 user group 776 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
3853 440 ----------+ 1 user group 450488 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Components.xml
3850 8 ----------+ 1 user group 6212 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_RegistryExcludes.xml
3840 4 ----------+ 1 user group 3138 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer0bada1de-01a9-4625-8278-69e735f39dd2.xml
3848 4 ----------+ 1 user group 2284 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer2707761b-2324-473d-88eb-eb007a359533.xml
3844 8 ----------+ 1 user group 5386 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
3846 4 ----------+ 1 user group 1488 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
3839 4 ----------+ 1 user group 1628 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer75dfb225-e2e4-4d39-9ac9-ffaff65ddf06.xml
3842 24 ----------+ 1 user group 21686 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writera65faa63-5ea8-4ebc-9dbd-a0c4db26912a.xml
3847 4 ----------+ 1 user group 1484 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
3845 4 ----------+ 1 user group 2940 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
3849 4 ----------+ 1 user group 1850 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writerb2014c9e-8711-4c5c-a5a9-3cf384484757.xml
3843 8 ----------+ 1 user group 6048 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
3838 4 ----------+ 1 user group 1746 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writerd61d61c8-d73a-4eee-8cdd-f6f9786b7124.xml
3841 13068 ----------+ 1 user group 13379228 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writere8132975-6f93-4464-a53e-1050253ae220.xml
3852 4 ----------+ 1 user group 758 Nov 3 14:44 BackupSpecs.xml
272 41249064 ----------+ 1 user group 42289070080 Nov 3 14:44 f7650533-11ca-4db4-80f5-2db42f7b900a.vhdx
したがって理論的には、これにより、ファイルをインプレースで置き換える増分バックアップと、たとえば同時に基礎となるBTRFSまたはZFS。テスト済みのWindows Server 2019のスナップショットのストレージを見ると、少なくともいくつかは実際にいくつかのスペースを共有しています。
Total Exclusive Set shared Filename
424.41GiB 417.69GiB 6.72GiB /volume1/@sharesnap/[...]/GMT+01-2019.10.29-00.00.09
446.53GiB 400.16GiB 46.37GiB /volume1/@sharesnap/[...]/GMT+01-2019.10.30-00.00.08
483.05GiB 448.36GiB 34.70GiB /volume1/@sharesnap/[...]/GMT+01-2019.10.31-00.00.08
553.78GiB 209.26GiB 344.52GiB /volume1/@sharesnap/[...]/GMT+01-2019.11.02-00.00.09
204.68GiB 204.63GiB 0.05GiB /volume1/@sharesnap/[...]/GMT+02-2019.10.01-00.00.07
410.24GiB 405.37GiB 4.87GiB /volume1/@sharesnap/[...]/GMT+02-2019.10.27-00.00.06
これは私が期待するほどではありませんが、ストレージが少なすぎるためにこのシステムのバックアップに問題が発生しているため、他の理由がある可能性があります。だからこそ、このトピックをもう一度調査し、この質問に答えました。イメージベースのバックアップを使用する他のWindows 10クライアントのスナップショットも見ると、それらの多くは、はるかに多くを共有しています。ただし、それらはZipベースのバックアップも使用し、BTRFSサブボリュームにはユーザーごとのすべてのバックアップ関連ディレクトリが含まれるため、数値は少し誤解を招く可能性があります。
問題は、VHDXファイルが再利用されても、共有されるスペースが少ない可能性があることです。これは、そのサーバーのC:のバックアップを後で呼び出すと、バックアップが速くならないようです。最初のバックアップは、多くのデータが変更されたために時間がかかる可能性がありますが、それが完了してサーバーが何も実行しない場合、ファイルの差分のみをバックアップするため、数分後の2番目のバックアップははるかに高速になります。しかし、そうではなく、以前と同じ時間がかかるようです。さらに、BTRFSはwbadminの異なる呼び出し間で作成されたスナップショットの違いをまったく同じコマンドラインで共有できますが、変更されたファイルのみを実際にバックアップする場合、予想よりもはるかに小さくなります。
root@[...]:~# btrfs filesystem du -s --gbytes /volume1/@sharesnap/[a-zA-Z]*/GMT*
Total Exclusive Set shared Filename
446.53GiB 400.20GiB 46.33GiB /volume1/@sharesnap/[...]/GMT+01-2019.10.30-00.00.08
483.05GiB 448.36GiB 34.70GiB /volume1/@sharesnap/[...]/GMT+01-2019.10.31-00.00.08
553.78GiB 546.54GiB 7.24GiB /volume1/@sharesnap/[...]/GMT+01-2019.11.02-00.00.09
39.35GiB 37.68GiB 1.67GiB /volume1/@sharesnap/[...]/GMT+01-2019.11.03-15.36.52
39.35GiB 31.18GiB 8.17GiB /volume1/@sharesnap/[...]/GMT+01-2019.11.03-15.49.03
39.35GiB 37.98GiB 1.37GiB /volume1/@sharesnap/[...]/GMT+01-2019.11.03-16.03.06
410.24GiB 409.72GiB 0.52GiB /volume1/@sharesnap/[...]/GMT+02-2019.10.27-00.00.06
これは、USBディスクにバックアップするときに表示されるものとは異なり、何も変更されていない場合、その後のバックアップははるかに高速です。興味深いのは、ネットワーク共有での動作もよくわからない人もいることです。
ネットワーク共有フォルダーまたはマップされたネットワークドライブへのスケジュールバックアップジョブを作成する場合、ネットワークの場所はボリュームではないため、すべてのバックアップは完全バックアップによってのみ実行されます。ネットワークフォルダへの差分バックアップまたは増分バックアップを作成する必要がある場合は、サードパーティのバックアップソフトウェアを使用する必要があります。
https://www.ubackup.com/windows-server/windows-server-backup-differential-4348.html
同じ人が次のように書いていますが、あまり意味がありません。
ヒント：次のように、WBADMINを使用してネットワーク共有に増分バックアップを作成することもできます。
wbadmin start backup –backupTarget：\ backupshare\backup1 -allCritical -include：C：-vssFull –quiet
https://www.ubackup.com/articles/wbadmin-incremental-backup-5740.html
古いバージョンのWindowsの場合のように、VHDが常に再作成される場合、共有にバックアップする場合、増分バックアップを取得できません。しかし、それらは保持され、USBディスクのような増分バックアップが可能であっても、-vssCopyをvssFullに変更しても、何も変更されないようです。バックアップの実行時間はどちらの場合もほぼ同じようです。
-vssFullおよび-vssCopyの影響。
フルバックアップ、増分バックアップ、差分バックアップに関して-vssFullと-vssCopyが何を行うかについては、たまにウェブ上で議論があります。私の意見では、変更ジャーナルは常に使用されるため、どちらの引数もwbengineがどのファイルをバックアップするかを決定する方法に影響を与えないだけです。 -vssCopyに関して混乱していると思われるのは、特に次の点です。
コピーバックアップは、増分または差分バックアップまたは復元には使用できません。
私の意見ではイメージベースのバックアップがどのように機能し、上記で説明されているため、MSがその警告で何を意味するのかわかりません。この文はwbadmin自体とはまったく関係ありませんが、サードパーティ製品ではなく、その仮定の下では、警告は-vssFullのドキュメントと一致していると思います
Windows Serverバックアップ以外の製品を使用して、現在のバックアップに含まれるボリューム上にあるアプリケーションをバックアップする場合は、このパラメーターを使用しないでください。[...]
-vssFullはファイルのアーカイブビットをリセットしますが、これらのビットは、どのセットアップでバックアップするファイルを決定するためにwbengineによっても使用されないと確信しています。代わりに、その引数は、追加のバックアップ関連のことを行う場合にのみ、他のアプリケーションに伝えます。
すべてのファイルがバックアップされ、各ファイルの履歴は、バックアップされたことを反映するように更新されます。以前のバックアップのログは切り捨てられる場合があります。[...]
ただし、それが変更ジャーナルに影響するかどうかはわかりません。どちらの引数にも次のステートメントが共通しているからではないでしょうか。
すべてのファイルがバックアップされます[...]
これらの議論の他の説明は、サードパーティのソフトウェアにも焦点を当てているようです：
したがって、VSSフルバックアップを実行すると、すべてのファイルのバックアップが作成されますが、その後、バックアップアプリケーションがファイルシステムのログを切り捨てることがあります。
これらのログは、Exchangeやデータベースなどのログであり、NTFSが独自に管理する変更ジャーナルではないと思います。上記と同じソース：
最後のテクニカルノート：バックアップタイプ（フル、コピー、インクリメンタル）は、IVssBackupComponents :: SetBackupStateを使用して、バックアップセッションの開始時にVSSベースのバックアップアプリケーションで指定できます。これに応じて、VSSライターを実装するアプリケーションは、OnBackupComplete VSSイベントのログを切り捨てることを選択できます。これは、VSSベースのバックアップアプリケーション（DPMなど）がバックアップセッションの最後に影響を受けるすべてのライターに送信する最後のイベントの1つです。
ですから、私の意見では、-vssFullと-vssCopyは、ファイルがバックアップされた後の動作にのみ影響し、バックアップするファイルやバックアップ方法には影響しないことは明らかです。 wbadminに対してまったく同じコマンドラインを-vssFullと-vssCopyだけでネットワーク共有に実行しても、VHD（X）に関しては何も変更されません。
「完全バックアップのように動作する」とは、完全バックアップを意味するものではありません。それはまだ増分バックアップシステムに基づいており、Veeamがずっと以前に行ったように、回復を改善するために最適化されたものにすぎません。以前のポイントが必要です。
ディスクを交換する場合は、両方のディスクのすべての増分ポイントを維持するために何かを行う必要があります。
問題を解決するには、2つの個別のジョブを構成し、特定のディスクがオンラインであることがわかっているときに実行するようにスケジュールする必要があります。例：1、3、5週目などにディスク1のジョブ1をスケジュールし、2、4、6週目などにディスク2のジャブ2をスケジュールします。間隔は任意に設定できます。バックアップは適切なディスクを見つけます。
詳細な手順については、 公式ガイドはこちら を参照してください。