La sauvegarde incrémentale automatique de Windows Server "fonctionne-t-elle bien" avec plusieurs disques de sauvegarde ?
A mon avis, oui.
Voici les arguments sur lesquels je fonde ma réponse, ce qui permet une discussion supplémentaire. Il y a encore quelques aspects de la façon dont Windows Backup se comporte dans certaines conditions dont je ne suis pas sûr et les gens pourraient vouloir clarifier ou corriger. Néanmoins, je pense qu'ils méritent d'être mentionnés ici.
La sauvegarde de Windows Server utilise-t-elle l'option 1 ou l'option 2 ? Et où cela est-il documenté ?
Tout d'abord, en général, je suis d'accord avec vous et je suis presque sûr que wbadmin / wbengine met en œuvre l'option 1, mais je n'ai pas de déclaration définitive le prouvant de la part de Microsoft également. Je suis également certain que ce problème n'est pas lié à Windows Server uniquement, mais qu'il fonctionne de la même manière pour les éditions non-Server de Windows. En fait, j'utilise exactement la configuration que vous avez mentionnée avec 3 disques USB différents depuis Windows 7 pour créer des sauvegardes basées sur des images. Un disque est hors site, deux disques changent régulièrement en une semaine.
Ce que je constate, c'est que les fichiers VHD(X) contenus sur les disques USB sont toujours mis à jour et que la durée des sauvegardes et les fichiers transférés dépendent réellement des fichiers qui ont changé depuis la dernière utilisation du disque USB utilisé comme cible de sauvegarde. C'est la partie incrémentale mentionnée dans vos docs, seulement les différences de sauvegarde, mais ces différences sont toujours écrites dans les fichiers existants dans le VHD(X).
Windows Image Backup NE GERE PAS l'historique incrémental des sauvegardes par lui-même, il écrase TOUJOURS les fichiers existants dans le VHD(X) actuellement utilisé comme cible de sauvegarde. Par conséquent, il n'y a JAMAIS d'historique incrémentiel nécessaire pour restaurer à partir du VHD(X) actuellement disponible. Dans le cas de disques USB formatés en NTFS, l'historique est implémenté en utilisant les éléments suivants Copies d'ombre de volume : Avant de faire une nouvelle sauvegarde, une copie fantôme est créée dans la cible de la sauvegarde, seulement après. wbengine ouvre le VHD(X) et remplace les fichiers qui s'y trouvent selon les besoins. Le remplacement des fichiers se fait IN-PLACE, BLOCK-BY-BLOCK, wbengine lit réellement les fichiers sources modifiés, compare les blocs lus aux mêmes blocs dans la cible de sauvegarde et n'écrase qu'en cas de modifications. Comme il y a une copie fantôme dans la cible de sauvegarde, VSS reconnaît ces blocs modifiés, qui sont en fait des blocs modifiés du VHD(X) en fin de compte, et copie les choses avant de les écraser. Ainsi, toutes les copies d'ombre dans la cible de sauvegarde contiennent toujours un VHD(X) entièrement fonctionnel du système précédemment sauvegardé et ces copies d'ombre créent un historique incrémentiel à la fin. Puisque toutes les copies d'ombre contiennent un VHD(X) entièrement fonctionnel, on n'a pas besoin de données incrémentielles supplémentaires, mais on peut simplement monter un snapshot, le VHD(X) dans ce snapshot et restaurer si nécessaire. VSS s'occupera des détails de la collecte des blocs associés.
Les points suivants sont ceux dont je ne suis pas sûr :
Comment Windows Image Backup décide-t-il des fichiers à sauvegarder ?
Windows/NTFS gère journaux des changements sur chaque volume, en gardant la trace de quel fichier a été modifié, comment il a été modifié et parce que ceux-ci font partie de tous les volumes NTFS par défaut, ils sont également disponibles dans le VHD(X) de la cible de sauvegarde. D'après ce que j'ai compris, wbengine compare simplement ces journaux pour savoir quels fichiers doivent être sauvegardés. Cela permet de supporter facilement différentes cibles de sauvegarde sans se soucier des bits d'archive des fichiers ou d'autres choses de ce genre, car ces journaux de changement sont liés à des ID de fichiers uniques au volume et ces ID sont exactement les mêmes dans la cible de sauvegarde :
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
Dans l'exemple ci-dessus, C:\ est le volume de mon système actuel tandis que D:\ est la dernière sauvegarde montée sur l'une des deux cibles de sauvegarde disponibles. Même les tailles de fichiers, les horodatages, etc. sont tous identiques :
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
En utilisant cette approche, la sauvegarde peut décider à tout moment avec n'importe quel VHD(X) plus ancien quels fichiers doivent être sauvegardés, tant que le journal actuel et celui de l'image ont quelque chose en commun, qui sont des ID d'entrée dans ma compréhension. Sans un tel ID partagé, par exemple, parce que trop d'E/S ont été productives et que la sauvegarde est trop ancienne, wbengine ferait simplement une sauvegarde complète au lieu d'une incrémentielle.
L'utilisation de ces journaux permet également de savoir assez rapidement quels fichiers sauvegarder, car il n'est pas nécessaire d'itérer l'ensemble de l'arbre des fichiers. C'est aussi ce que l'on voit en pratique : Backup semble savoir assez rapidement quels fichiers sauvegarder et commence à les traiter au lieu d'itérer l'arbre des fichiers.
Comportement en cas de partages réseau comme cible de sauvegarde pour Windows Server 2008 R2.
Dans le cas d'une sauvegarde sur des partages réseau, quel est le nom de l'utilisateur ? wbengine Cela semble dépendre de la version de Windows utilisée, mais en général, l'approche décrite précédemment, qui consiste à n'avoir qu'un seul VHD(X) par volume sauvegardé dans la cible de sauvegarde, semble également valable. La principale différence semble être la manière d'y parvenir, soit en écrasant les fichiers VHD(X) existants, en les supprimant et en les recréant, soit, comme c'est le cas avec les disques USB, en les ouvrant et en les modifiant sur place.
Voici ce que disent certains médecins et d'autres personnes à ce sujet :
Si vous enregistrez une sauvegarde dans un dossier partagé distant, cette sauvegarde sera écrasée si vous utilisez à nouveau le même dossier pour sauvegarder le même ordinateur [...].
https://docs.microsoft.com/en-us/previous-versions/Windows/it-pro/Windows-server-2008-R2-and-2008/cc742130(v=ws.10)
Notez que si vous sauvegardez sur un partage réseau, une sauvegarde complète sera exécutée à chaque fois (parce que VSS n'est pas disponible), écrasant la sauvegarde complète précédente. Dans ce cas, il n'y a pas de politique de sauvegarde du tout, vous maintenez simplement une copie à distance du système.
https://lennox-it.uk/a-complete-guide-to-wbadmin-Windows-backups
Cela dépend du support sur lequel tu effectues la sauvegarde. Si la sauvegarde s'effectue sur un disque dur, elle est toujours incrémentielle. Si la sauvegarde est effectuée sur un partage, il s'agit toujours d'une sauvegarde complète, la dernière sauvegarde étant écrasée.
https://administrator.de/forum/verständnisfragen-Windows-server-backup-2012-294395.html
D'après mes propres tests sous Windows 2008 R2, le terme "écrasé" semble être un peu trompeur ici, car il semble que de nouveaux fichiers soient créés, car non seulement les noms des images changent, mais aussi leurs inodes :
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
C'est différent de ce que je vois sur mes disques USB, où les images conservent leurs noms et leurs identifiants de fichiers (/inodes) et seuls la plupart des fichiers XML obtiennent de nouveaux UUID. Sur les disques USB, le répertoire parent du VHD(X) change également, mais il s'agit simplement d'un renommage qui n'influence en rien les fichiers enfants. A un moment donné pendant les tests, j'ai réussi à ce que wbengine a décidé de garder les noms des fichiers VHD, mais leur inode change toujours. Je n'ai pas invoqué avec une nouvelle ligne de commande, mais simplement par la suite :
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
Je ne sais pas pourquoi ils ont implémenté les choses de cette façon en cas d'utilisation de partages, car cela casse par exemple les clichés BTRFS sous-jacents. Mais c'est exactement ce que je vois : Tous les snapshots que mon NAS crée pour le dossier où je stocke ces sauvegardes ont presque tout le stockage associé exclusivement au lieu de partager de grandes parties des données. De plus, d'après les tailles des fichiers journaux et les durées d'exécution de wbengine En effet, toutes les sauvegardes prennent presque le même temps, même si les fichiers de la source sauvegardée ne changent pas beaucoup.
Comportement en cas de partages réseau comme cible de sauvegarde pour Windows Server 2012+.
Les choses semblent être un peu différentes avec les nouvelles versions de Windows : Je suis presque sûr qu'un de mes clients a eu des problèmes avec wbadmin et Windows Server 2012 et pendant le débogage de ceux-ci à l'aide de Process Monitor, j'ai vérifié que les fichiers VHDX existants étaient conservés au lieu d'être supprimés et recréés. Je l'ai testé en ce moment même avec Windows Server 2019 à nouveau et de multiples invocations de wbadmin a conduit à des sauvegardes réussies tout en gardant les inodes des fichiers VHDX identiques :
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
Donc, en théorie, cela devrait permettre des sauvegardes incrémentielles remplaçant des fichiers sur place et des instantanés efficaces, par exemple, de BTRFS ou ZFS sous-jacents en même temps. En regardant le stockage des instantanés du Windows Server 2019 testé, au moins certains d'entre eux partagent vraiment de l'espace :
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
Ce n'est pas autant que ce à quoi je m'attendais, mais cela pourrait avoir d'autres raisons, car ce système a des difficultés à sauvegarder en raison d'un manque de stockage. C'est en fait la raison pour laquelle j'étudie à nouveau ce sujet et que je suis arrivé à cette question. En regardant les instantanés d'autres clients Windows 10 qui utilisent également des sauvegardes basées sur des images, on constate qu'ils partagent beaucoup plus. Mais ceux-ci utilisent également la sauvegarde basée sur le format ZIP et les sous-volumes BTRFS contiennent tous les répertoires liés à la sauvegarde par utilisateur, les chiffres peuvent donc être un peu trompeurs.
Le fait est qu'il se peut que peu d'espace soit partagé même si les fichiers VHDX sont réutilisés, car lorsque j'invoque ensuite la sauvegarde C: de ce serveur, la sauvegarde ne semble pas s'accélérer. La première sauvegarde peut prendre plus de temps car beaucoup de données ont été modifiées, mais une fois cette opération terminée et alors que le serveur ne fait rien, une deuxième sauvegarde quelques minutes plus tard devrait être beaucoup plus rapide, car elle ne sauvegarde que les différences entre les fichiers. Mais cela ne semble pas être le cas, au contraire, cela semble prendre le même temps qu'avant. De plus, alors que BTRFS peut partager les différences dans les instantanés créés entre différentes invocations de la commande wbadmin avec exactement la même ligne de commande, ceux-ci sont beaucoup plus petits que prévu alors qu'ils ne sauvegardent que les fichiers modifiés :
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
C'est différent de ce que je constate lors de mes sauvegardes sur mes disques USB, les sauvegardes suivantes sont beaucoup plus rapides si rien n'a changé. Ce qui est intéressant, c'est que d'autres semblent ne pas être aussi sûrs de la façon dont les choses se comportent sur les partages réseau :
Si vous créez une tâche de sauvegarde programmée vers un dossier partagé en réseau ou un lecteur réseau mappé, toutes les sauvegardes ne seront effectuées que par une sauvegarde complète car l'emplacement réseau n'est pas un volume. Si vous avez besoin de créer une sauvegarde différentielle ou incrémentale vers un dossier réseau, vous devez utiliser un logiciel de sauvegarde tiers.
https://www.ubackup.com/Windows-server/Windows-server-backup-differential-4348.html
Alors que les mêmes personnes écrivent ce qui suit, qui n'a pas beaucoup de sens :
Astuce : Vous pouvez également utiliser WBADMIN pour créer une sauvegarde incrémentale vers un partage réseau, comme ceci :
wbadmin start backup -backupTarget : \backupshare\backup1 -allCritical -include:C : -vssFull -quiet
https://www.ubackup.com/articles/wbadmin-incremental-backup-5740.html
Si le VHD est toujours recréé, comme cela semble être le cas pour les anciennes versions de Windows, en cas de sauvegarde sur des partages, on n'obtient pas de sauvegardes incrémentielles. Mais même si ces dernières sont conservées et que des sauvegardes incrémentielles comme avec des disques USB seraient possibles, le fait de modifier le VHD ne permet pas d'effectuer des sauvegardes incrémentielles. -vssCopy à vssFull ne semble pas changer quoi que ce soit pour moi. La durée d'exécution des sauvegardes semble être à peu près la même dans les deux cas.
Influence de -vssFull et -vssCopy.
Il y a de temps en temps une discussion sur le web à propos de ce que -vssFull y -vssCopy fait concernant les sauvegardes complètes, incrémentielles et différentielles. A mon avis, ces deux arguments n'influencent tout simplement pas la manière dont les wbengine ne décide pas du tout des fichiers à sauvegarder, car les journaux des modifications sont toujours utilisés. Ce qui semble déroutant concernant -vssCopy est surtout le suivant :
Une copie de sauvegarde ne peut pas être utilisée pour des sauvegardes ou des restaurations incrémentielles ou différentielles.
https://docs.microsoft.com/en-us/previous-versions/Windows/it-pro/Windows-server-2008-R2-and-2008/cc742130(v=ws.10)
En raison de la façon dont les sauvegardes basées sur des images fonctionnent à mon avis et décrites ci-dessus, je n'ai aucune idée de ce que MS veut dire avec cet avertissement. Je suppose fortement que cette phrase n'est PAS liée à wbadmin mais plutôt des produits tiers. Dans cette hypothèse, l'avertissement serait conforme à ce qui est documenté pour les produits de l -vssFull
N'utilisez pas ce paramètre si vous utilisez un produit autre que Windows Server Backup pour sauvegarder les applications qui se trouvent sur les volumes inclus dans la sauvegarde en cours. [...].
Même si -vssFull réinitialise les bits d'archive des fichiers, je suis toujours convaincu que ces bits ne sont PAS utilisés par wbengine pour décider des fichiers à sauvegarder dans n'importe quelle configuration. Au lieu de cela, cet argument indique aux autres applications seulement si elles doivent faire des choses supplémentaires liées à la sauvegarde :
Tous les fichiers sont sauvegardés, l'historique de chaque fichier est mis à jour pour refléter le fait qu'il a été sauvegardé, et les journaux des sauvegardes précédentes peuvent être tronqués [...].
Je ne suis pas sûr que cela influence les journaux de changement, cependant. Je suppose que non, car les deux arguments ont en commun la déclaration suivante :
Tous les fichiers sont sauvegardés [...]
D'autres explications de ces arguments semblent également porter sur les logiciels tiers :
Ainsi, lorsque vous effectuez une sauvegarde complète VSS, vous créez une sauvegarde de tous les fichiers - mais après cela, l'application de sauvegarde peut tronquer les journaux sur le système de fichiers.
https://techcommunity.microsoft.com/t5/Storage-at-Microsoft/What-is-the-difference-between-VSS-Full-Backup-and-VSS-Copy/ba-p/423575
Ces journaux sont ceux d'Exchange ou des bases de données ou autre, je suppose que ce ne sont pas les journaux de changement que NTFS gère seul. Même source que ci-dessus :
Une dernière note technique : le type de sauvegarde (complet, copie, incrémentiel) peut être spécifié par une application de sauvegarde basée sur VSS au début de la session de sauvegarde, en utilisant la fonction IVssBackupComponents: : SetBackupState . En réponse à cela, toute application qui implémente un graveur VSS peut choisir de tronquer les journaux dans l'événement VSS OnBackupComplete. Il s'agit de l'un des derniers événements qu'une application de sauvegarde basée sur VSS (telle que DPM) envoie à tous les rédacteurs concernés à la fin de la session de sauvegarde.
Donc, à mon avis, il est clair que -vssFull y -vssCopy n'influence que le comportement des choses APRÈS que les fichiers aient été sauvegardés et n'influence PAS les fichiers à sauvegarder ou la façon dont ils sont sauvegardés. En exécutant exactement la même ligne de commande pour wbadmin avec seulement -vssFull vs. -vssCopy vers un partage réseau ne change rien au VHD(X) également pour moi.
0 votes
I pensez à L'option 1 est la façon dont wbadmin gère cela, parce que la sauvegarde précédente n'est pas trouvée dans le référentiel de sauvegarde du disque cible, il va en créer une complète. Je n'ai pas de documentation, cependant. Je l'essaierais simplement si j'étais vous. Modifier : trouvé un fil dans lequel il est discuté. Pour 2008R2, vous deviez ajouter le deuxième disque de sauvegarde via la ligne de commande, ce qui peut maintenant être fait en utilisant l'interface graphique également.
0 votes
Vérifiez également ce fil de discussion SF Je ne sais pas si c'est une copie exacte.
0 votes
@Lenniey : Merci, j'ai vu ce fil de discussion. Heureusement, l'ajout d'un deuxième disque est beaucoup plus facile maintenant. J'ai également pensez à que c'est l'option 1 (parce qu'autrement le fait qu'elle "se comporte comme une sauvegarde complète" ne serait pas satisfaite), mais je veux juste m'en assurer - les sauvegardes sont trop importantes pour se fier à son instinct. Les tests sont difficiles, car Windows Server Backup effectue parfois des sauvegardes complètes par lui-même (même s'il ne fait pas partie de la liste de sauvegarde). pourrait faire une sauvegarde incrémentale), donc je ne peux pas déduire le comportement futur en regardant les sauvegardes précédentes.
0 votes
Avez-vous essayé de faire une restauration à partir de la sauvegarde hors site comme test ? Il semblait cassé quand j'ai essayé.
1 votes
@Louis : Non, malheureusement, puisque je ne veux pas acheter un deuxième serveur coûteux (ou au moins beaucoup de disques durs) juste pour faire un test de restauration. J'ai cependant essayé d'extraire manuellement des fichiers de la sauvegarde, ce qui a fonctionné (voir mon auto-réponse sur cette question ).