Skip to main content
  • EN

Hallo allerseits,

ich habe hier ein Projekt, bei dem ich auf die LTO9 Bänder die Sicherungssätze gern 2-3x ans LTO Band anhängen möchte.

Ausgangssituation mit Backup Exec:

Ich bin offenbar sehr verwöhnt vom Backup Exec (BE), denn das beherrscht das (anhängen) ohne große Probleme. So kann ich hier bspw. meine Mediensätze erstellen und dort definieren, wie lange die Bänder des Mediensatzes schreibgeschützt und anhängbar sind.

Wenn ich dem Mediensatz sage, dass er 3 Wochen Anhängezeitraum hat, kann ich entsprechend 3 Sicherungen auf mein LTO schreiben lassen und halte so einen netten Sicherungsvorhaltezeitraum bereit.

Für unsere Kunden mit BE lassen wir so in der Regel Montag bis Donnerstag (Mediansatz Mo-Do) täglich sichern und 2-3 mal anhängen, bis komplett überschrieben wird.

Außerdem lassen wir Freitags die Bänder Freitag 1 bis 5 beschreiben und haben darüber ebenfalls einen entsprechend langen Vorhaltezeitraum zur Verfügung.

Nun sei der Vollständigkeit halber erwähnt, dass wir fast ausschließlich Vollbackups auf die LTO Bänder schreiben lasen, was in 95% der Fälle gut klappt.

Nun der Swing die BE Gegebenheiten aufs Veeam anzuwenden:

Soweit ich das für’s Veeam eruieren konnte, geht das (anhängen) nur mit GFS Mediensätzen?

Nun habe ich mir also einen neuen GFS Mediensatz und einen Tape Job erstellt und hier die Optionen für das tägliche (Dienstag bis Freitag ab 05.00Uhr) und das wöchentliche (Samstag ab 05.00Uhr) Backup gesetzt.

Merkwürdigerweise ist der Sicherungsjob heute um 11Uhr gestartet, obwohl ich mehrfach die Startzeit von 5 Uhr kontrolliert habe… Sicherung lief durch, wie ich aber eben feststellte, muss das ein Bug gewesen sein, denn nachdem ich die Startzeit geändert und den Job gespeichert habe, veränderte sich das Startzeitfenster auf die korrekte Uhrzeit… wieder zurück auf 05.00Uhr, ging auch… sei es drum.

Während ich hier also schreibe und auch nochmals recherchiere, überlege ich, ob meine ”BE Denke” so in der Form überhaupt für Veeam anwendbar ist. Ich vermute, dass das Kernproblem ist, dass ich mit Veeam keine täglichen Vollbackups erstelle und der GFS Ansatz in der Form nicht meine Lösung für die Handhabung mit BE ist.

Vielleicht denke ich auch nur zu kompliziert und will deshalb mein Ziel mal formulieren:

  • Die Sicherungskapazität der LTO9 Bänder soll möglichst gut ausgeschöpft werden. Wenn ich 2-4 Sicherungssätze (hier gehe ich gedanklich eigentlich von einem Vollbackup aus) auf ein Band bekomme, warum das nicht nutzen, statt jedes Mal das Band zu überschreiben?
  • Im Sinne des Kunden möchte ich so viele Sicherungen auf LTO vorhalten wie möglich.
  • Montag bis Donnerstag für die tägliche Sicherung, Freitag 1 bis 5, für die wöchentliche. Freitag 5 hat den Vorteil, dass dieser nur ca. alls 2, 3 Monate greift. Die Vorhaltezeit wird damit also weiter gestreckt.

Hoffe ich war verständlich mit meinem Anliegen und ihr habt etwas Input für mich.

Mhh, irgendwie denkst du sehr kompliziert.

Im Prinzip kannst du deine Backups zum Beispiel mit einem Tape Backup Job auf Tape kopieren. Solange Platz auf dem Band ist, werden die Backups auf das Band geschrieben.

Wenn du die Aufteilung zwischen den Tages und Wochen Backups haben willst, kannst du entweder zwei Backup Jobs einrichten oder du nutzt einen GFS Job.

Wobei der GFS Job die Tages und Wochen Backups nicht auf verschiedene Tapes schreibt.

Hast du einen besonderen Grund warum alle Backups Full Backups sein sollen?

Im Prinzip kannst du deine Backups zum Beispiel mit einem Tape Backup Job auf Tape kopieren. Solange Platz auf dem Band ist, werden die Backups auf das Band geschrieben.

 

Genau das passiert ja eben nicht. Bei den ersten Tape Jobs war es bisher so, dass das Band bzw. die Bänder einen ”Expires in” Status bzw. Datum gesetzt haben. Wenn dieses Datum nach dem aktuell geplanten Tape Job liegt, ist das Band schreibgeschützt.

Aber wo ich diese Zeilen so gerade schreibe und die Einstellungen des Media Pools noch mal prüfe kommt mir gerade die Frage auf: Womöglich ist die Einstellung “Protect data for xx days” einfach falsch und ich muss die Option “Do not protect data” auswählen?

Die Option hatte ich bisher immer glatt ausgeklammert, weil mir diese rein vom Wording her ein “überschreibe das Band immer/jedes Mal” bedeutete… gemäß Erläuterung in der Veeam online Hilfe scheint das aber nicht zwingend der Fall zu sein?

If this option is selected, tapes allocated to the pool will be overwritten, starting with the tape that stores the oldest archive.

Demnach würde Veeam erst dann mit überschreiben anfangen, wenn ein Band das älteste Archiv vorhält?

Frage dann aber: Was bedeutet das konkret?

 

Die Notes weiter unten:

If at the previous step you selected the Do not create, always continue using current media set option, note that the retention period for such media sets starts after the first tape in the media set becomes full.

würde ich dann aber so deuten, dass quasi bei Verwendung von Montag bis Donnerstag und Freitag 1 bis 5  in jedem Fall dann ”von vorn angefangen” wird, wenn das allererste Band voll ist?

Kann gerade nicht folgen, was das in der Praxis bedeutet und wie ich vorab kalkulieren kann, wie lang die Retention Dauer dann sein wird…

Wenn du die Aufteilung zwischen den Tages und Wochen Backups haben willst, kannst du entweder zwei Backup Jobs einrichten oder du nutzt einen GFS Job.

Wobei der GFS Job die Tages und Wochen Backups nicht auf verschiedene Tapes schreibt.

Hast du einen besonderen Grund warum alle Backups Full Backups sein sollen?

Ja so habe ich das bisher eingestellt: Ein Job für Montag bis Donnerstag und ein Job für Freitag 1 bis 5.

Ich werde das ”Konzept” jetzt wie folgt umstellen:

  1. Montag bis Donnerstag als Backup To Tape Job, also als quasi Secondary Target des B2D Jobs.
  2. Freitag 1 bis 5 als File to Tape Backup

Damit bekomme ich zwar dann, nach meinem Verständnis der Arbeitsweise vom Veeam, nur 1x in der Woche eine Komplettsicherung (Freitag 1 bis 5) der B2D Daten hin aber das scheint mir noch immer besser  zu handhaben als das ”GFS Zeugs”.

 

Bezüglich Deiner Frage zum Vollbackup: Ich hab es nicht gern, wenn ich bzw. die Kunden dem Risiko ausgesetzt sind, das Datenverlust wegen eines defekten Bandes möglich ist. Ein Vollbackup ist ein Vollbackup und ich muss im Bedarfsfall nicht LTO Jockey spielen...

Nun, die Option “protect data for xx” tut eigentlich genau das was drauf steht. Damit stellst du ein wie lange ein Backup aufbewahrt werden soll. Klappt bei mir auch ohne Probleme…

Wenn dann allerdings duie Backups länger aufbewahrt werden als Platz auf dem Band ist für neue Backups in dieser Zeit, brauchst du mehr Bänder.

 

Wie ist deine Hardware? Hast du ein einzelnes Laufwerk bei dem du manuell jeden Tag das Tape wechselst oder hast du eine Library? Wenn du manuell wechselst, muss ich zugeben, dass ich das noch nie ausprobiert habe wie Veeam damit zurecht kommt.

Ja genau, ist ein LTO9 Laufwerk… klar mit Library ist es an einigen Stellen anders. Da kann Veeam auch einfach beigehen und sich ein freies Band schnappen und man kann bzw. muss das Sicherungskonzept noch  anders ausrichten.

Ich teste es jetzt mal mit der Do not protect data… Option.

Schade, dass Veeam in der Online Hilfe hier sehr dürftig ausgestattet ist und vor allem keine Beispiele bringt.

 

Die Protect data for xxx Option ist, soweit ich sie verstehe, so gestrickt, dass sie das verwendete Medium mit einem Überschreibschutz versieht. Anhängen ist hier im Medien Pool ja nicht mal eine Option, im GFS aber schon.

Bei Backup Exec ist anhängen für einen Bandspeicher Medienpool quasi immer aktivierbar, aber eben auch kein muss. Ich bin da total flexibel.

Ich denke einfach, dass hier 2 Hersteller mit einigen grundlegend anderen Ansätzen rangehen und Veritas hier historisch einfach im Vorteil ist, da Veeam stets und allererst eine B2D Lösung war, während Veritas noch aus seinen Urzeiten schon immer Band konnte…

Ich gebe mal ein Update, ob das mit der neuen Einstellung klappt. Dürfte aber mindestens 1-2 Wochen dauern, bis ich hier erste Ergebnisse habe.

Danke erstmal fürs Feedback!

 

Comment


Terms & Conditions