Konsolidierung großer Snapshots

[Lionel Hutts]

Hallo zusammen,

mir ist kürzlich aufgefallen, dass der "Veeam backup running snapshot" nach Vollenden des jeweiligen Jobs leider nicht mehr gelöscht wird und die delta Datei mittlerweile ziemlich angewachsen ist.

Für die Zukunft werde ich auf jeden Fall das Snapshot Monitoring im vCenter aktivieren. Ich möchte am Wochenende die Snapshots konsolidieren.

Ich habe hier folgende Konfiguration:
PowerEdge R510 (PERC H700 Integrierter RAID Controller, 512MB Cache; SAS 15k 3,5 Zoll) mit ESXi 4.0.0 build-261974
PowerEdge R310 mit vCenter 4.0.0 build-258672
Veeam Backup & Replication 4.1.1

2 VMs
1.) -flat.vmdk 10 GB
_1-flat.vmdk 300 GB
-000001-delta.vmdk 7,9 GB
_1-000001-delta.vmdk 117 GB

2.) -flat.vmdk 1 TB
-000001-delta.vmdk 313 GB

Freier Speicherplatz im Datastore: 437 GB

Bei der Veeam Replikation heute früh dauerte die Konsolidierung von 6,6 GB ca. 10 Minuten. Somit rechne ich bei VM1 (125 GB) mit ca. 3,5 h und bei VM2 (313 GB) mit ca. 9 h.

Ich möchte wie folgt vorgehen:
- heute Abend starten wegen der hohen IO-Last
- Veeam-Jobs deaktivieren
- beide VMs nacheinander konsolidieren
- über vCenter im Snapshot-Manager das Veeam Snapshot löschen

Ich habe mich in die Thematik und eventuelle Probleme eingelesen und hätte hierzu einige Fragen bevor ich starte:
- Kann ich die Konsolidierung bei laufender VM durchführen? Das Helper Snapshot müsste genug Platz haben.
- Kann die parental Disk beim Konsolidieren kaputt gehen?
- Lauern noch andere mögliche Gefahren?
- Muss ich die time outs im vCenter anpassen, vgl. KB1004790 oder ist es nicht nötig?

Vielen Dank im Voraus.

Lionel

[continuum]

- Kann ich die Konsolidierung bei laufender VM durchführen? Das Helper Snapshot müsste genug Platz haben.

Ja - aber dann dauert es laenger

- Kann die parental Disk beim Konsolidieren kaputt gehen?

JA ! - aber nur in extrem unguenstigen Faellen - deiner sieht mir aber nicht danach aus.

In deinem Fall wuerde ich beide VMs herunterfahren um Zeit zu sparen.
Dann mach erst VM 1 und danach VM 2

Brech eine laufende Consolierung auf keinen Fall ab - auch wenn sie schon seit Stunden bei 99 % zu haengen scheint

[Lionel Hutts]

Danke für die Tipps Ulli.

Ja, die gewohnte Fortschrittsanzeige "Snapshot wird gelöscht" 95% oder 99%.
Ich werde per SSH den time stamp der parental disk prüfen.

[Supi]

Wenn du schon ein Vcenter hast, dann auch gleich mal über Update 2 bzw gleich Update 3 für den Host nachdenken.
Als erstes aber immer das Vcenter aktualisieren.

[Lionel Hutts]

Ich möchte euch das Ergebnis nicht vorenthalten.

Nach interner Rücksprache musste ich die Konsolidierung doch bei laufenden VMs durchführen und diese ging trotzdem überraschend schnell.
Bei VM 1 (7,9 + 117,2 GB) dauerte der Vorgang 68 Minuten und bei VM 2 (313,1 GB) war das Löschen nach 86 Minuten abgeschlossen.

Die Konsolidierung läuft seitdem bei allen Replikationsjobs klaglos.
Ich habe jetzt herausgefunden, dass der "Veeam backup running snapshot" ein Überbleibsel eines Failovers war und es vergessen wurde diesen zu löschen.

Es sind noch einige roll back files, _working.VMDKs und Konsorten von diesem Vorgang auf dem Produktivserver übrig geblieben. Kann ich diese (fett markiert) gefahrlos löschen?

1.6G Jul 26 2010 2010-07-25T231220-s001.vrb
422 Jul 26 2010 2010-07-25T231220.vrb
1.6G Jul 26 2010 2010-07-26T125400-s001.vrb
422 Jul 26 2010 2010-07-26T125400.vrb
2.0G Jun 10 2011 KMS-15699e09.vswp
13 Jul 26 2010 KMS-aux.xml
640.5k Feb 27 08:13 KMS-ctk.vmdk
10.0G Feb 27 10:24 KMS-flat.vmdk
8.5k Oct 30 07:20 KMS.nvram
562 Feb 27 08:13 KMS.vmdk
1.1k Feb 27 08:13 KMS.vmsd
3.3k Feb 27 08:13 KMS.vmx
2.9k Jul 30 2010 KMS.vmxf
4.7M Feb 27 08:13 KMS_1-ctk.vmdk
300.0G Feb 27 10:24 KMS_1-flat.vmdk
594 Feb 27 08:13 KMS_1.vmdk
486 Jul 26 2010 KMS_1_working.vmdk
482 Jul 26 2010 KMS_working.vmdk
55.5M Jul 26 2010 replica-s001.vbk
412 Jul 26 2010 replica.vbk
39.5M Jul 26 2010 running-s001.rbk
412 Jul 26 2010 running.rbk

3.1G Jul 26 2010 2010-07-25T231220-s001.vrb
422 Jul 26 2010 2010-07-25T231220.vrb
3.9G Jul 26 2010 2010-07-26T125400-s001.vrb
422 Jul 26 2010 2010-07-26T125400.vrb
8.0M Feb 27 08:55 SRV01-ctk.vmdk
10.0G Oct 1 21:57 SRV01-d69e48df.vswp
1.0T Feb 27 10:26 SRV01-flat.vmdk
8.5k Feb 26 17:09 SRV01.nvram
590 Feb 27 08:55 SRV01.vmdk
920 Feb 27 08:55 SRV01.vmsd
2.9k Feb 27 08:55 SRV01.vmx
1.8k Oct 1 21:56 SRV01.vmxf
485 Jul 26 2010 SRV01_working.vmdk
95.5M Jul 26 2010 replica-s001.vbk
412 Jul 26 2010 replica.vbk
39.5M Jul 26 2010 running-s001.rbk
412 Jul 26 2010 running.rbk

Gruß,
Lionel

[continuum]

wenn du dir nicht sicher bist ob du files loeschen kannst - benenn sie erst mal um bei laufender VM.
Wenn das geht - und wenn die VM sich auch danach noch neustarten laesst kannst du die dann gefahrlos loeschen

[irix]

Nun,
alle genannten Files sind keine welche der ESX Host selber erstellt hat bzw. benoetigt. Ich wuerde also man den Veeam Support bemuehen und mir erklaeren lassen was davon noch benoetigt wird. An deren Erkenntnissen darfst du uns dann ruhig teilhaben lassen.

Gruss
Joerg

[continuum]

Stimmt - da haben dann alle was davon

[Lionel Hutts]

Gerade habe ich eine Antwort vom Veeam Support erhalten und ja, man darf nach einem erfolgreich durchgeführten Failover die fettmarkierten Dateien löschen.

Ich habe gestern noch zum Thema Failover mit Veeam B&R diese detaillierte Anleitung gefunden, vgl. 2. Beitrag:
http://forums.veeam.com/viewtopic.php?p=30976

Gruß,
Lionel