12
Veeam 9.5, Backupstorage vollgelaufen
Hallo.
Ich nutze Veeam Backup & Replication 9.5 zur Sicherung von 10 virtuellen Maschinen.
Nun ist der Backupstorage vollgelaufen, es sind noch 4 MegaByte von circa 10 TeraByte frei.
Ich hab mir nun den im Sommer erstellten Plan angesehen.
Eigentlich sollte jeden Sonntag ein Wochenbackup aus den Tagesbackups geschrieben werden und jeden Monat ein Monatsbackup aus den Wochenbackups, und jedes Jahr ein Jahresbackup aus den Monatsbackups, und das vorerst mal 5 Jahre lang, so der Plan.
So sieht der Plan aus:
Ich hab' jetzt zunächst auch nicht den Eindruck, daß mit dem Plan etwas nicht stimmt.
Trotzdem ist der Storage gerammelt voll. Deshalb hab' ich nun eine virtuelle Maschine, die nicht sicherungswürdig ist, entfernt (vorher waren es also 11, jetzt noch 10).
Dies allein scheint aber nicht zu helfen, ich hab' mir deshalb jetzt mal die geschriebenen Backups angesehen:
Dabei fällt auf, daß hier momentan insgesamt 7 Wochenbackups "herumliegen" - eigentlich dürften es doch, je nach Länge eines Monats, höchstens 5 Stück sein? Ich war bisher der Meinung, daß die Wochenbackups nach Zusammenfassung ins jeweilige Monatsbackup gelöscht werden und nur die des laufenden Monats, der noch nicht vorüber ist, stehenbleiben. Demnach müßten es eigentlich 2 Wochenbackups weniger sein, die mir 2 Terabyte Speicherplatz sparen würden.
Was muß ich ändern, hab' ich evtl. doch falsch geplant oder irgendwo einen Denkfehler? Muß ich evtl. die "Restore-Points-To-Keep" verringern? Und wie würde sich das auf meine Planung auswirken?
Vielen Dank.
Viele Grüße
von
departure69
Ich nutze Veeam Backup & Replication 9.5 zur Sicherung von 10 virtuellen Maschinen.
Nun ist der Backupstorage vollgelaufen, es sind noch 4 MegaByte von circa 10 TeraByte frei.
Ich hab mir nun den im Sommer erstellten Plan angesehen.
Eigentlich sollte jeden Sonntag ein Wochenbackup aus den Tagesbackups geschrieben werden und jeden Monat ein Monatsbackup aus den Wochenbackups, und jedes Jahr ein Jahresbackup aus den Monatsbackups, und das vorerst mal 5 Jahre lang, so der Plan.
So sieht der Plan aus:
Ich hab' jetzt zunächst auch nicht den Eindruck, daß mit dem Plan etwas nicht stimmt.
Trotzdem ist der Storage gerammelt voll. Deshalb hab' ich nun eine virtuelle Maschine, die nicht sicherungswürdig ist, entfernt (vorher waren es also 11, jetzt noch 10).
Dies allein scheint aber nicht zu helfen, ich hab' mir deshalb jetzt mal die geschriebenen Backups angesehen:
Dabei fällt auf, daß hier momentan insgesamt 7 Wochenbackups "herumliegen" - eigentlich dürften es doch, je nach Länge eines Monats, höchstens 5 Stück sein? Ich war bisher der Meinung, daß die Wochenbackups nach Zusammenfassung ins jeweilige Monatsbackup gelöscht werden und nur die des laufenden Monats, der noch nicht vorüber ist, stehenbleiben. Demnach müßten es eigentlich 2 Wochenbackups weniger sein, die mir 2 Terabyte Speicherplatz sparen würden.
Was muß ich ändern, hab' ich evtl. doch falsch geplant oder irgendwo einen Denkfehler? Muß ich evtl. die "Restore-Points-To-Keep" verringern? Und wie würde sich das auf meine Planung auswirken?
Vielen Dank.
Viele Grüße
von
departure69
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 394652
Url: https://administrator.de/contentid/394652
Printed on: April 26, 2024 at 18:04 o'clock
12 Comments
Latest comment
Deine Retention Policy passt nicht.
https://helpcenter.veeam.com/docs/backup/vsphere/backup_copy_simple_rete ...
https://helpcenter.veeam.com/docs/backup/vsphere/backup_copy_simple_rete ...
Zitat von @falscher-sperrstatus:
Deine Retention Policy passt nicht.
https://helpcenter.veeam.com/docs/backup/vsphere/backup_copy_simple_rete ...
Deine Retention Policy passt nicht.
https://helpcenter.veeam.com/docs/backup/vsphere/backup_copy_simple_rete ...
Genau das
Hhmmm, Du meinst damit, daß ich zu viele Voll-Backups stehen lasse?
Moin,
es kann natürlich auch sein, das dein Repository für dein Volumen einfach zu klein ist, wenn du unbedingt 30 Restore Points pro VM erhalten willst.
lg,
Slainte
es kann natürlich auch sein, das dein Repository für dein Volumen einfach zu klein ist, wenn du unbedingt 30 Restore Points pro VM erhalten willst.
lg,
Slainte
Zitat von @SlainteMhath:
Moin,
es kann natürlich auch sein, das dein Repository für dein Volumen einfach zu klein ist, wenn du unbedingt 30 Restore Points pro VM erhalten willst.
lg,
Slainte
Moin,
es kann natürlich auch sein, das dein Repository für dein Volumen einfach zu klein ist, wenn du unbedingt 30 Restore Points pro VM erhalten willst.
lg,
Slainte
Das war ja Teil meiner Frage, sind die Restore-Points zu viele? Und was passiert, wenn ich die Anzahl mal auf beispielsweise 22 reduziere? Genügt es dann, den Job mal von Hand zu starten, oder muß ich von Hand im Dateisystem etwas löschen, um im Repository wieder Platz zu schaffen?
Das war ja Teil meiner Frage, sind die Restore-Points zu viele?
Aus Storage Sicht: jaWie da aus Sicht deiner Backup-Stratgie/Anforderung aussieht musst du selbst entscheiden.
Und was passiert, wenn ich die Anzahl mal auf beispielsweise 22 reduziere? Genügt es dann, den Job mal von Hand zu starten,
Normaler weise würde das genügen. Wenn der Platz allerdings gen 0 geht dann nicht mehr.muß ich von Hand im Dateisystem etwas löschen, um im Repository wieder Platz zu schaffen?
Ja musst du.ab ich würde vorher im Repository nachsehen welche vbk'a/vlb's Sinn mach zu löschenJa musst du.ab ich würde vorher im Repository nachsehen welche vbk'a/vlb's Sinn mach zu löschen
Nunja, ganz simpel stell' ich mir vor, die beiden ältesten "Weekly" zu löschen. Die beiden aus Oktober, die ja eigentlich für das Oktober-"Monthly" nicht mehr benötigt werden sollten, denn das Oktober-"Monthly" ist ja schon geschrieben. Ich weiß bloß nicht (und bin deshalb etwas ängstlich), ob solch eine "harte" Löschaktion nicht die ganze Chain, wo ein Backup auf das vorherige aufbaut, zerstört.
vbk = full backup, steht für sich allein
vib = inkrementell, teil einer Chain bzw baut auf vbk auf.
vib = inkrementell, teil einer Chain bzw baut auf vbk auf.
Hi,
Veeam macht alles korrekt.
Du hast 30 Restore Points, das sind alle Sicherungen, eingetragen und dann muss Veeam dir auch 30 Versionen vorhalten, egal was darunter steht.
Diese zählen erst danach.
Da aber ein Inkrementelles Backup alleine nicht läuft, muss auch das dazu gehörige Vollbackup verwahrt werden, also können das auch 35 Versionen sein.
Auch hast du nicht geschrieben was im Backup selber drinsteht, das hier ist nur die Backup-Copy.
Wenn du dort auch 30 Restore-Points, hast du alles doppelt.
VG,
Deepsys
Veeam macht alles korrekt.
Du hast 30 Restore Points, das sind alle Sicherungen, eingetragen und dann muss Veeam dir auch 30 Versionen vorhalten, egal was darunter steht.
Diese zählen erst danach.
Da aber ein Inkrementelles Backup alleine nicht läuft, muss auch das dazu gehörige Vollbackup verwahrt werden, also können das auch 35 Versionen sein.
Auch hast du nicht geschrieben was im Backup selber drinsteht, das hier ist nur die Backup-Copy.
Wenn du dort auch 30 Restore-Points, hast du alles doppelt.
VG,
Deepsys
Zitat von @SlainteMhath:
vbk = full backup, steht für sich allein
vib = inkrementell, teil einer Chain bzw baut auf vbk auf.
vbk = full backup, steht für sich allein
vib = inkrementell, teil einer Chain bzw baut auf vbk auf.
Ja, ist mir klar, die beiden Oktober-"Weekly", die ich löschen möchte, sind *.vbk, sollte also dahingehend erstmal passen.
Hab' zum Glück auch nicht behauptet, daß Veeam blöd ist, das bin dann wohl eher ich Du hast 30 Restore Points, das sind alle Sicherungen, eingetragen und dann muss Veeam dir auch 30 Versionen vorhalten, egal was darunter steht.
Diese zählen erst danach.
Hab' die Restore-Points nun vorerst mal auf 22 reduziert.
Da aber ein Inkrementelles Backup alleine nicht läuft, muss auch das dazu gehörige Vollbackup verwahrt werden, also können das auch 35 Versionen sein.
O. K.
Auch hast du nicht geschrieben was im Backup selber drinsteht, das hier ist nur die Backup-Copy.
Wenn du dort auch 30 Restore-Points, hast du alles doppelt.
Die beiden Repositories verfolgen verschiedene Zwecke. Das "Haupt"-Repository hält mir tatsächlich ebenfalls 30 Restore-Points vor, jedoch keine wöchentlichen, monatlichen oder jährlichen Backups, es dient einfach nur dazu, VMs mit dem Stand der jüngsten, letzten Zeit wiederherstellen zu können. Dort gibt es auch keinen Platzmangel (gleiche Storage-Größe wie beim Copy-Repository).
Das Copy-Repository soll hingegen das Langzeit-Archiv sein, deshalb speziell dort "Weekly", "Monthly" und "Yearly".
Hab' jetzt die beiden "Weekly" aus Oktober manuell gelöscht und das Copy-Backup von Hand ausgelöst. Logischerweise läuft und funktioniert es nun wieder, da ja wieder freier Platz da ist, die Löschung hat knapp 2 TB eingebracht
.Letzt dumme Frage, dann seid Ihr mich Nervensäge wieder los: Wie weit kann ich beim Copy-Backup-Job die Anzahl der Restore-Points noch verringern, ohne die Archivierung Weekly-Monthly-Yearly zu gefährden?
Nochmals danke.
Viele Grüße
von
departure69
VG,
Deepsys
Zitat von @departure69:
Letzt dumme Frage, dann seid Ihr mich Nervensäge wieder los: Wie weit kann ich beim Copy-Backup-Job die Anzahl der Restore-Points noch verringern, ohne die Archivierung Weekly-Monthly-Yearly zu gefährden?
Letzt dumme Frage, dann seid Ihr mich Nervensäge wieder los: Wie weit kann ich beim Copy-Backup-Job die Anzahl der Restore-Points noch verringern, ohne die Archivierung Weekly-Monthly-Yearly zu gefährden?
Hmm, ich mach das Archiv per Tape.
Aber wenn du den Backup-Copy nur alle 5 Tage laufen lässt, könnte das evtl. darüber gehen .... Oder mal den Veeam Support fragen