20
Backupstrategie mit Veeam und Tapes
Moin zusammen,
Ich bin zum ersten Mal in den Genuss einer vollen Veeam Lizenz und einer Tape Library gekommen. Ich tüftele mir gerade eine Backup Strategie aus:
Das HDD Raid Set ist groß genug um 2-3 Jahre lang die VMs mit ihren täglichen Restore Points zu sichern. Aktuell sammelten sich Restore Points von ca 1 Jahr an.
Ich möchte nun die Restore Points auf der Platte behalten, jedoch monatlich auf Band weg sichern und in die Zweigstelle schicken.
Zusätzlich möchte ich jährlich auf WORM Tapes sichern und in die Zweigstelle sichern.
Nur, wie erstelle ich mit Veeam B&R eine Tape Sicherung, die nur einen Monat an Restore Points enthält? Ich kann zwar in Veeam die VMs oder das Repository auswählen, die gesichert werden sollen, aber dann werden "alle" vorhandenen Restore Points dieser VM oder des Repositories auf Tape geschieben. Sowas, wie einen Zeitfilter habe ich in Veeam nicht entdeckt.
Ich könnte aber auch 3 Repositories erzeugen "daily repo", "monthly repo", "yearly repo" und dort per Retention Policy bestimmen, dass die Monthly Repo Daten älter als 1 Monat wieder löscht. Und dann diese Monthly Repo auf Band sichern. Das würde jedoch bedeuten, dass ich alle Daten in 3 Repos 3-fach vorhanden habe, also das 3-fache an Speicherplatz benötige.
Geht das auch irgendwie anders / effektiver? Ich habe in den Eigenschaften des Backup Jobs (VMs zum Raid Set) die Einstellungen entdeckt, wie lange es die weekly, monthly und yearly full backups aufheben soll, bevor sie wieder bereinigt werden. Nur sehe ich keine Möglichkeit "nur" diese auf Band zu bekommen ohne alle anderen Restore Points mit zu sichern. Wie würde das Best Practice aussehen?
Danke Euch and keep rockin'
Der Mike
Ich bin zum ersten Mal in den Genuss einer vollen Veeam Lizenz und einer Tape Library gekommen. Ich tüftele mir gerade eine Backup Strategie aus:
Das HDD Raid Set ist groß genug um 2-3 Jahre lang die VMs mit ihren täglichen Restore Points zu sichern. Aktuell sammelten sich Restore Points von ca 1 Jahr an.
Ich möchte nun die Restore Points auf der Platte behalten, jedoch monatlich auf Band weg sichern und in die Zweigstelle schicken.
Zusätzlich möchte ich jährlich auf WORM Tapes sichern und in die Zweigstelle sichern.
Nur, wie erstelle ich mit Veeam B&R eine Tape Sicherung, die nur einen Monat an Restore Points enthält? Ich kann zwar in Veeam die VMs oder das Repository auswählen, die gesichert werden sollen, aber dann werden "alle" vorhandenen Restore Points dieser VM oder des Repositories auf Tape geschieben. Sowas, wie einen Zeitfilter habe ich in Veeam nicht entdeckt.
Ich könnte aber auch 3 Repositories erzeugen "daily repo", "monthly repo", "yearly repo" und dort per Retention Policy bestimmen, dass die Monthly Repo Daten älter als 1 Monat wieder löscht. Und dann diese Monthly Repo auf Band sichern. Das würde jedoch bedeuten, dass ich alle Daten in 3 Repos 3-fach vorhanden habe, also das 3-fache an Speicherplatz benötige.
Geht das auch irgendwie anders / effektiver? Ich habe in den Eigenschaften des Backup Jobs (VMs zum Raid Set) die Einstellungen entdeckt, wie lange es die weekly, monthly und yearly full backups aufheben soll, bevor sie wieder bereinigt werden. Nur sehe ich keine Möglichkeit "nur" diese auf Band zu bekommen ohne alle anderen Restore Points mit zu sichern. Wie würde das Best Practice aussehen?
Danke Euch and keep rockin'
Der Mike
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 63735896518
Url: https://administrator.de/forum/backupstrategie-mit-veeam-und-tapes-63735896518.html
Ausgedruckt am: 22.12.2024 um 08:12 Uhr
20 Kommentare
Neuester Kommentar
Moin.
Option #1
Ich bin mir nicht mehr sicher, aber die Enterprise Version hat hierfür mehr Optionen. Ich behelfe mir mit Option #1, da die dadurch zusätzlich benötigten Festplatten günstiger waren.
Option #1
- Du einen extra Job mit einem active full backup, Zyklus 1 Monat
- Diesen Ordner sicherst du dann auf Band.
- Der Ordner wird danach wieder gelöscht
Ich bin mir nicht mehr sicher, aber die Enterprise Version hat hierfür mehr Optionen. Ich behelfe mir mit Option #1, da die dadurch zusätzlich benötigten Festplatten günstiger waren.
1
Danke schon mal, das käme der Idee mit dem zweiten Repository gleich. Beides erzeugt einen doppelten Speicherplatzbedarf.
Konzeptfrage:
Warum willst du die Restore-Points / Snapshots sichern?
Üblich ist m.E. die VM nicht als VM sondern wie ein physischer Host zu sichern.
Also regelmäßig ein Full-Backup des Servers und dazwischen - z.B. täglich ein Differenz-Backup.
Eine Sicherung der VM würde als Export stattfinden, wonach der Export auf Band gesichert wird ...
Dann logischerweise mit allen Restore-Points/Snapshots die nicht in die VM integriert sind ..
.. mit allen Risiken.
Überhaupt sollte man von Zeit zu Zeit die Snapshots integrieren, wenn sicher ist, das dieser Restore-Point sicher ist ...
Warum willst du die Restore-Points / Snapshots sichern?
Üblich ist m.E. die VM nicht als VM sondern wie ein physischer Host zu sichern.
Also regelmäßig ein Full-Backup des Servers und dazwischen - z.B. täglich ein Differenz-Backup.
Eine Sicherung der VM würde als Export stattfinden, wonach der Export auf Band gesichert wird ...
Dann logischerweise mit allen Restore-Points/Snapshots die nicht in die VM integriert sind ..
.. mit allen Risiken.
Überhaupt sollte man von Zeit zu Zeit die Snapshots integrieren, wenn sicher ist, das dieser Restore-Point sicher ist ...
Jup, die Bänder lege ich entsprechend weg: Tag, Woche, Monat, Jahr,... je nach Anforderung der Aufbewahrungszeit. Der Ablauf geht auch mit der CE Edition (V12 müsste ich aber verifizieren ob das noch so ist), wenn man nur 10 Server mit "Bewegungsdaten" hat kann man die so "kostenlos" sichern lassen, vom Rest tut es ab und ein ein Export per Script.
Also egal wieviel Platz du so hast auf deiner Festplatte, ich würde dir folgendes Empfehlen:
Wöchentlich Fullbackup und rest inkrementel.
Und Tapes eben Wöchentlich ein neuen Satz Tapes benutzen, wenn du glück hast passt die ganze woche auf ein Tape und wenn nicht haste halt 2 Tapes. Und somit haste von jeder Kalenderwoche einen Satz Tapes.
Und die Tapes welche du langfristig aufbewahren willst holst du halt raus, z.B. Monatlich, Halbjährlich oder Jährlich.
Optimaler weise führst du einfach Wöchentlich eine Excel Liste mit wo du dir Tape Nummer und Datum reinnotierst.
Wir haben die Tapes Wöchentlich zur Bank gebracht und dort Wochen Tapes 1 Jahr gelagert, nach einem jahr nur noch quartalssicherungen dort gelassen und nach 3 Jahren nur noch Jahres Sicherungen.
Anhand der Excel liste lässt sich dann einfach planen welche Tapes man zum überschreiben wieder einlegen wird.
Bei den Tapes ein sinnvolles Datum wählen ab wann sie wieder überschrieben werden dürfen, bei uns war es nach 1 Jahr.
Und welchen Wochensatz du dann letztendlich Long Term technisch aufbewahrst, ist dann nur einen Entscheidungssache und keine Technische Sache.
So einen Zyklus auf einen Monat machen würd ich nicht, bedeutet 1 Full Backup pro Monat und dann Inkrementel 30 Tage lang... weil wenn das Full Backup ein Problem hat, verlierst du gleich mal 1 Monat an sicherungen... Wenn du eine Woche verlieren würdest ist das eher tolerierbar...
Ist nur mal meine Meinung dazu.
Wöchentlich Fullbackup und rest inkrementel.
Und Tapes eben Wöchentlich ein neuen Satz Tapes benutzen, wenn du glück hast passt die ganze woche auf ein Tape und wenn nicht haste halt 2 Tapes. Und somit haste von jeder Kalenderwoche einen Satz Tapes.
Und die Tapes welche du langfristig aufbewahren willst holst du halt raus, z.B. Monatlich, Halbjährlich oder Jährlich.
Optimaler weise führst du einfach Wöchentlich eine Excel Liste mit wo du dir Tape Nummer und Datum reinnotierst.
Wir haben die Tapes Wöchentlich zur Bank gebracht und dort Wochen Tapes 1 Jahr gelagert, nach einem jahr nur noch quartalssicherungen dort gelassen und nach 3 Jahren nur noch Jahres Sicherungen.
Anhand der Excel liste lässt sich dann einfach planen welche Tapes man zum überschreiben wieder einlegen wird.
Bei den Tapes ein sinnvolles Datum wählen ab wann sie wieder überschrieben werden dürfen, bei uns war es nach 1 Jahr.
Und welchen Wochensatz du dann letztendlich Long Term technisch aufbewahrst, ist dann nur einen Entscheidungssache und keine Technische Sache.
So einen Zyklus auf einen Monat machen würd ich nicht, bedeutet 1 Full Backup pro Monat und dann Inkrementel 30 Tage lang... weil wenn das Full Backup ein Problem hat, verlierst du gleich mal 1 Monat an sicherungen... Wenn du eine Woche verlieren würdest ist das eher tolerierbar...
Ist nur mal meine Meinung dazu.
Danke Mirko...
Nein, ich habe keine Snapshots. Nur Restore Points, also die Sicherungen selbst.
Danke Pinky,,
machst du die wöchentliche Sicherung und die täglichen inkrementellen Sicherungen über einen Job in eine Repository? Auch da ergibt sich die Frage wie man nur 1 Woche davon auf Band bekommt - ausser, man löscht die älteren Restore Points von der Platte.
Nein, ich habe keine Snapshots. Nur Restore Points, also die Sicherungen selbst.
Danke Pinky,,
machst du die wöchentliche Sicherung und die täglichen inkrementellen Sicherungen über einen Job in eine Repository? Auch da ergibt sich die Frage wie man nur 1 Woche davon auf Band bekommt - ausser, man löscht die älteren Restore Points von der Platte.
Du musst bei den Media Pool einstellen an welchem Wochentag/Uhrzeit eine neuer Backup Set (Tapes) angefangen werden soll.
Bedeutet bei uns war das so das am Samstag Abend das FULL gemacht wurde. Im Media Set konnte man irgendwo einstellen das z.B. jeden Samstag ab 20 Uhr ein neuer Satz erstellt werden soll.
Also landet das neu erstelllte FULL als erstes auf dem neuen Satz Tapes, und jeden abend dannach das Inkrementelle.
Bis zum Samstag wieder weil das spiel von vorne losgeht.
Leider kann ich im detail nicht nachschauen da ich nicht mehr dort arbeite um das detailierter zu beschreiben.
EDIT Habs nochmal nachgelesen:
Also im Media Pool kannste festlegen wann Tapes überschrieben werden können.
Und da kannst auch bei Media Set >> Create New Media Set >> Eben den Tag definieren und Uhrzeit wann.
Daily at >> Uhrzeit >> On these Days >> Days Definieren.
Geht aber nur bei normalem Medial Pool nicht bei GFS Media Pool
Bedeutet bei uns war das so das am Samstag Abend das FULL gemacht wurde. Im Media Set konnte man irgendwo einstellen das z.B. jeden Samstag ab 20 Uhr ein neuer Satz erstellt werden soll.
Also landet das neu erstelllte FULL als erstes auf dem neuen Satz Tapes, und jeden abend dannach das Inkrementelle.
Bis zum Samstag wieder weil das spiel von vorne losgeht.
Leider kann ich im detail nicht nachschauen da ich nicht mehr dort arbeite um das detailierter zu beschreiben.
EDIT Habs nochmal nachgelesen:
Also im Media Pool kannste festlegen wann Tapes überschrieben werden können.
Und da kannst auch bei Media Set >> Create New Media Set >> Eben den Tag definieren und Uhrzeit wann.
Daily at >> Uhrzeit >> On these Days >> Days Definieren.
Geht aber nur bei normalem Medial Pool nicht bei GFS Media Pool
Zitat von @NordicMike:
machst du die wöchentliche Sicherung und die täglichen inkrementellen Sicherungen über einen Job in eine Repository? Auch da ergibt sich die Frage wie man nur 1 Woche davon auf Band bekommt - ausser, man löscht die älteren Restore Points von der Platte.
Man kann auch mehrere Backupjobs laufen lassen (Halt mit dem Full Backup am gleichen Tag) und dann im Tape Job mehrere Backup Jobs inkludieren.
Das er beim erstenmal alle Backups im Repository auf Tape machen will... könnte sein.
Er will halt alles backupen was er noch nicht gebackupt hat. Aber da bin ich mir im Detail nicht mehr so sicher wie ich das gemacht habe, ist halt auch schon 3,5 Jahre her
Moin,
Wir haben das ähnlich wie du (nur ohne WORM):
Leg in Summe zwei MediaPools an:
Dann zwei Jobs
So haben wir es im groben (ist auch schon länger her und komme getragen nicht dran)
Wir haben das ähnlich wie du (nur ohne WORM):
Leg in Summe zwei MediaPools an:
- Tape_Daily
- Tape_Monthly
Dann zwei Jobs
- Backup2Tape Daily
- Backup2Tape Monthly
So haben wir es im groben (ist auch schon länger her und komme getragen nicht dran)
OK, danke euch. Es scheint so der Stand der Dinge zu sein, dass der Datenbestand doppelt (oder dreifach, je nach dem) auf dem Raid Set zu verweilen hat. Dann plane ich das mal so ein.
Zitat von @NordicMike:
OK, danke euch. Es scheint so der Stand der Dinge zu sein, dass der Datenbestand doppelt (oder dreifach, je nach dem) auf dem Raid Set zu verweilen hat. Dann plane ich das mal so ein.
In deinem Fall schon.OK, danke euch. Es scheint so der Stand der Dinge zu sein, dass der Datenbestand doppelt (oder dreifach, je nach dem) auf dem Raid Set zu verweilen hat. Dann plane ich das mal so ein.
Option #2
- immer das gleiche backup-to-disk Verzeichnis
- jede Woche ein neues fullback, nach dem backup to tape wird alles gelöscht
Nachteil
Ich muss immer vom Band zurücksichern, wenn ich etwas älter als eine Woche brauch.
Nachteil
Danke Dir, genau meine Überlegung, in diesem Fall würde ich mich jedoch lieber für den doppelten Platzbedarf entscheiden, die Tapes gehen ja auch noch außer Haus oder ich müsste noch ein weiteres Tape Set für mich mit sichern.Nein, ich habe keine Snapshots. Nur Restore Points, also die Sicherungen selbst.
Warum sichert ihr die VMs eigentlich nicht per Snapshot?Kommt ein (derzeit) nicht Unterstützer Hypervisor zum Einsatz?
Jetzt kann ich mal etwas mehr zu unserem Konstrukt berichten.
Wir haben sichern 1x unsere VMs (VMware) und dann noch eine Hand voll FatClients.
Die VMs werden für 60 Tage Versioniert. An jedem Sonntag findet ein synthetisches Backup statt.
Zudem gibt es div. GFS-Regeln..
Target beim 2Disk-Job ist immer nur ein und dasselbe ScaleOut-Repository
DiskPool01"MediaPools fürdie Tape gibt es 2: Daily und Weekly
- Daily hat keine Retention hinterlegt, bzw. gibt es keine DataProtection (das müsste ich für uns noch mal hinterfragen)
- Weekly hat eine Retention von 26 Wochen
Nachdem alle 2Disk-Jobs durch sind, sorgt der letzte 2Disk-Job dafür, dass der
Daily2Tape Job startet.Der sichert immer den aktuellen Datenbestand unter
DiskPool01 wegEinmal pro Woche haben wir noch einen weiteren Tape-Job:
Weekly2Tape. Der sichert wiederum ebenfalls den aktuellen Bestand aus DiskPool01, verwendet aber den MediaPool Weekly. Hier wird das Band dann obendrein in den I/O-Slot transportiert.In diesem Konstrukt bedarf es nur ein Disk-Repository und dennoch werden die Bänder unterschiedlich lange aufbewahrt.
Was aber etwas unglücklich an Veeam ist: Will man Monatsweise Bänder erstellen, kann ich nicht sagen "an jedem 1. eines Monats um 01:00 Uhr soll das Band
Monthly erstellt werden. Der kann nur "jeden ersten Montag/ Dienstag/ ... im Monat". Wobei das auch durchaus sinnvoll sein kann. Dann hat man immer ganze Wochen auf einem band vorliegen, was insbesondere bzgl. des Synthetischen FullBackups sinnvoll sein kann..Edit:
Unter Strich erfüllt das obige aber nicht ganz deinem Wunsch: sichere nur die Daten des letzten Monats (Pool
Monthly bzw. Jahres (Pool Weekly) weg.Das würde maximal über irgendwelche GFS-Richtlinien klappen.
Die Frage wäre aber, was du auf dem Jahres-Band sehen willst. Tatsächlich alle RestorePoints (oder Snapshots oder was auch immer) von Januar bis Dezember?
Warum sichert ihr die VMs eigentlich nicht per Snapshot?
Kommt ein (derzeit) nicht Unterstützer Hypervisor zum Einsatz?
Veeam erzeugt doch selbst Snapshots auf dem Hyper-V um die VM zu sichern. Da muss ich nicht selbst noch welche erzeugen. Veeam löscht sie auch nach der getanen Sicherung brav.Kommt ein (derzeit) nicht Unterstützer Hypervisor zum Einsatz?
Das mit dem synthetischen Backup hatte ich bisher nicht auf dem Schirm, ich muss mal genau schauen wie sich das unter Veeam verhält.
Zitat von @NordicMike:
Ach, OK. also werden im Grunde genommen doch Snapshots gesichert. Dann passt das ja Warum sichert ihr die VMs eigentlich nicht per Snapshot?
Kommt ein (derzeit) nicht Unterstützer Hypervisor zum Einsatz?
Veeam erzeugt doch selbst Snapshots auf dem Hyper-V um die VM zu sichern. Da muss ich nicht selbst noch welche erzeugen. Veeam löscht sie auch nach der getanen Sicherung brav.Kommt ein (derzeit) nicht Unterstützer Hypervisor zum Einsatz?
Das mit dem synthetischen Backup hatte ich bisher nicht auf dem Schirm, ich muss mal genau schauen wie sich das unter Veeam verhält.
Läuft hier fluffig. Halten die einzelnen Snapshots der täglichen Sicherungen für 30 Tage. Einmal pro Woche werden synth. FullBackups generiert, die wiederum xx Wochen, yy Monate und zz Jahre aufbewahrt werden.Rennt hier ganz gut und funktioniert sogar beim Restore.
Vorteil durch die synth. FullBackups: deine Kette bleibt beim Restore überschaubar...
Hier mal ein Beispiel:
Increment die täglichen Snapshots (dazwischen gibt es noch ein paar Full-Restore-Points
Full (M) ist eine Monatssicherung gemäß GFS
Full (Y) ist eine Jahressicherung gemäß GFS
Was im Screenshot noch fehlt ist auch die jüngste Variante Full (WM), da am WE eine Wochen- und eine Monatssicherung statt fand.
Zitat von @em-pie:
Einmal pro Woche haben wir noch einen weiteren Tape-Job: Weekly2Tape. Der sichert wiederum ebenfalls den aktuellen Bestand aus DiskPool01
Er sichert immer den gesamten Bestand, also siehst du dann in dieser Sicherung die Restore Points von 60 Tagen, richtig?Einmal pro Woche haben wir noch einen weiteren Tape-Job: Weekly2Tape. Der sichert wiederum ebenfalls den aktuellen Bestand aus DiskPool01
Er sichert immer den gesamten Bestand, also siehst du dann in dieser Sicherung die Restore Points von 60 Tagen, richtig?
Korrekt.
Habe ich das Tape vom 01.03. (OK. vom letzten Samstag im Monat) in der Hand, kann ich über dieses Tape noch auf die RestorePoints der letzten 60 Tage + die Bestände gemäß GFS zurückgreifen.
Mithilfe der Bänder komme ich also eigentlich immer weitgenug zurück - das, was auf Disk ist, brauche ich ja eher für "ich ha da heute morgen versehentlich das gesamte Abteilungslaufwerk geleert" bzw. für Probleme, die mit einer VM entstanden sind und einen Restore von vor 10 Tagen erfordern (Nutzdaten kann man ja meistens übernehmen).
OK, in dem Fall würde es nicht klappen, wenn ich auf den Platten Restore Points von 1 Jahr aufheben möchte.
Ich habe noch keine Erfahrung wie groß der Unterschied im Bänderverbrauch ist, wenn ich 1 Monat Restore Points oder 1 Jahr Restore Points auf den Bändern habe. Ich könnte mir vorstellen, dass der gar nicht so groß ist.
Ich habe noch keine Erfahrung wie groß der Unterschied im Bänderverbrauch ist, wenn ich 1 Monat Restore Points oder 1 Jahr Restore Points auf den Bändern habe. Ich könnte mir vorstellen, dass der gar nicht so groß ist.
OK, in dem Fall würde es nicht klappen, wenn ich auf den Platten Restore Points von 1 Jahr aufheben möchte.
Korrekt - aber willst du wirklich von jedem Server 365 RestorePoints aufbewahren? Also habt ihr tatsächlich die Anforderung, Daten vom 07.07.2023 wiederherstellen zu können zu müssen? Also wie oft kommt das vor?Wir lagern die Monatsbänder ein und haben dadurch ja die Möglichkeit, über die Monatsbänder dann auf jeden einzelnen Tag zurückgreifen zu können. Der Restore dauert zwar etwas länger, aber bisweilen habe ich noch nicht soweit zurück gehen müssen...
So war zunächst mal der Nice To Have Gedanke und die Findung ob es machbar ist. Natürlich ist es kein Muss. Ich muss halt jetzt Plattenplatz und Bänderanzahl kalkulieren und evaluieren was wichtiger wäre...
