Tage später - habe einiges probiert - jetzt wirds lang
Natürlich — hier ist die
anonymisierte und etwas gestraffte Fassung. Ich habe ersetzt:
Zwei Tape-Backup-Jobs mit einem Standalone-Laufwerk: neues Media Set zwischen den Jobs
Hallo zusammen,
ich betreibe einen
Proxmox Backup Server 4.2.4 mit einem einzelnen
Standalone-LTO-8-Laufwerk.
Da ein Tape-Backup-Job derzeit nur einen Datastore sichern kann, habe ich zwei getrennte Tape-Backup-Jobs für zwei Datastores eingerichtet.
Konfiguration
Hardware
- Proxmox Backup Server 4.2.4
- ein Standalone-LTO-8-Laufwerk
- kein Tape-Changer
Media Pool
- gemeinsamer Media Pool für beide Jobs
- Allocation Policy: daily
- CreateAt-Ereignis: 00:00
- Retention: 6 days
- Medien können wiederverwendet werden, sobald die Retention dies erlaubt
Tape-Backup-Job A
- Datastore A
- Zeitplan: 05:00
- Latest Only: aktiviert
- Eject Media: deaktiviert
Tape-Backup-Job B
- Datastore B
- Zeitplan: 05:15
- Latest Only: aktiviert
- Eject Media: aktiviert
Gewünschter Ablauf
Der gewünschte Ablauf:
- Job A startet um 05:00 Uhr.
- Job A eröffnet aufgrund der Allocation Policy ein neues tägliches Media Set.
- Job A schreibt die Daten von Datastore A auf das angeforderte Tape.
- Job A beendet den Sicherungslauf, wirft das Tape aber nicht aus.
- Job B wartet währenddessen auf den Drive Lock.
- Nach Ende von Job A übernimmt Job B das Laufwerk.
- Job B verwendet dasselbe Media Set und schreibt auf demselben Tape weiter.
- Job B schreibt am Ende den aktualisierten Medienkatalog.
- Job B wirft das Tape aus.
Job B soll somit kein eigenes Media Set eröffnen, sondern das von Job A begonnene Media Set fortsetzen.
Funktionierender Fall
Wenn das angeforderte Tape noch am selben Tag eingelegt wird und Job A sowie Job B direkt nacheinander laufen, funktioniert der Ablauf wie gewünscht.
Job A eröffnet ein neues Media Set und schreibt auf Tape A.
Nach dem erfolgreichen Ende von Job A übernimmt Job B unmittelbar den Drive Lock. Job B zeigt dieselbe Media-Set-UUID wie Job A und verwendet ebenfalls Tape A.
Im Log von Job B erscheinen dann unter anderem folgende Meldungen:
- media set uuid: <identisch mit Job A>
- allocated new writable media 'Tape A'
- found media label Tape A
- moving to end of media
- arrived at end of media
Job B schreibt damit hinter den Daten von Job A weiter.
Am Ende von Job B erscheinen:
- percentage done: 100.00%
- append media catalog
- standalone drive - ejecting media
- TASK OK
Der gewünschte Ablauf funktioniert in diesem Fall vollständig:
Job A → Job B → gleiches Media Set → gleiches Tape → Auswurf durch Job B
Problemfall bei längerer Wartezeit
Das Problem tritt auf, wenn Job A längere Zeit auf das angeforderte Tape wartet und dabei weitere tägliche CreateAt-Zeitpunkte verstreichen.
(Trödeligkeit, vergessen Tape zu wechseln, Abwesenheit - das Leben halt!)
In einem konkreten Fall war der Ablauf folgender:
- Job A startete am ersten Tag um 05:00 Uhr.
- Job A eröffnete Media Set A und forderte Tape A an.
- Job B startete um 05:15 Uhr und wartete auf den Drive Lock.
- Tape A wurde erst ungefähr 50 Stunden später eingelegt.
- Job A schrieb anschließend erfolgreich auf Tape A.
- Job A endete mit TASK OK.
- Job B erhielt danach den Drive Lock.
Job B verwendete jedoch nicht das bereits von Job A eröffnete Media Set.
Stattdessen meldete Job B:
- starting new media set - reason: policy CreateAt event triggered
- eine neue Media-Set-UUID
- allocated new writable media 'Tape B'
Das von Job A verwendete Tape A befand sich noch im Laufwerk, wurde von Job B jedoch abgelehnt:
- wrong media label Tape A
- Please insert media 'Tape B' into drive
Job B setzte den Sicherungslauf erst fort, nachdem Tape B eingelegt worden war.
Das Ergebnis war damit:
Job A → Tape A → Media Set A
und anschließend:
Job B → Tape B → Media Set B
Statt des gewünschten Ablaufs:
Job A → Job B → Tape A → gemeinsames Media Set
Vermutete Ursache
Der Zeitpunkt, zu dem Job B durch den Zeitplan erzeugt wurde, scheint für die Media-Pool-Allocation nicht allein maßgeblich zu sein.
Job B wurde zwar bereits am ersten Tag um 05:15 Uhr gestartet und wartete seitdem auf den Drive Lock. Die Allocation Policy beziehungsweise das CreateAt-Ereignis scheint jedoch erneut ausgewertet zu werden, wenn Job B tatsächlich den Drive Lock erhält und mit dem Tape-Backup beginnt.
Da zwischen Jobstart und tatsächlichem Beginn weitere tägliche CreateAt-Zeitpunkte verstrichen waren, eröffnete Job B ein neues Media Set.
Das Verhalten unterscheidet sich somit abhängig von der Wartezeit:
Kurze Wartezeit
Job A und Job B laufen innerhalb derselben Allocation-Periode:
Job A → Job B → gleiches Media Set → gleiches Tape
Lange Wartezeit
Zwischen Job A und dem tatsächlichen Beginn von Job B verstreichen weitere CreateAt-Zeitpunkte:
Job A → Media Set A → erneutes CreateAt → Job B → Media Set B
Auswirkungen
Das Verhalten hat bei einem Standalone-Laufwerk mehrere praktische Auswirkungen:
- Job B schreibt nicht auf dem von Job A verwendeten Tape weiter.
- Für einen zusammengehörigen Sicherungslauf werden zwei Tapes benötigt.
- Das erste Tape wird nicht ausgeworfen.
- Job A ist absichtlich mit Eject Media: No konfiguriert.
- Nur Job B besitzt Eject Media: Yes.
- Wenn Job B ein anderes Tape verlangt, kann Job B das erste Tape nicht auswerfen.
- Der gewünschte gemeinsame Tages-Mediensatz wird auf zwei Media Sets aufgeteilt.
- Während der längeren Wartezeit können weitere geplante Tape-Jobs auflaufen und ebenfalls auf den Drive Lock warten.
Verhalten mit Allocation Policy
Die Allocation Policy continue wurde ebenfalls geprüft.
Mit continue entsteht kein neues tägliches CreateAt-Ereignis zwischen Job A und Job B. Beide Jobs können daher grundsätzlich das aktuelle Media Set fortsetzen.
Das löst jedoch nicht die vollständige Anforderung.
Gewünscht ist:
- ein neues Media Set pro Tag beziehungsweise Sicherungslauf,
- aber ein gemeinsames Media Set für beide Datastores.
Mit continue wird das aktuelle Media Set potenziell über mehrere Tage und mehrere Sicherungsläufe hinweg weitergeführt.
Es ergibt sich damit folgender Zielkonflikt:
Allocation Policy
Vorteil:
- Es entsteht regelmäßig ein neues Media Set.
Nachteil:
- Wenn Job A über einen weiteren CreateAt-Zeitpunkt hinweg auf das Tape wartet, kann Job B später ein neues Media Set eröffnen.
Allocation Policy
Vorteil:
- Zwischen Job A und Job B entsteht kein neues zeitgesteuertes Media Set.
Nachteil:
- Das Media Set wird auch über weitere Tage hinweg fortgesetzt.
- Die gewünschte tägliche Media-Set-Grenze fehlt.
Gewünschte Verbesserung
Die aus meiner Sicht sauberste Lösung wäre, in einem Tape-Backup-Job mehrere Datastores auswählen zu können.
Beispielsweise:
- Datastore A
- Datastore B
- ein gemeinsamer Media Pool
- ein gemeinsames Media Set
- einmalige Auswertung der Allocation Policy
- ein abschließender Medienkatalog
- einmaliger Auswurf nach Abschluss aller Datastores
Der gesamte Ablauf könnte dann als ein zusammenhängender Task behandelt werden:
Media Set eröffnen → Datastore A sichern → Datastore B sichern → Medienkatalog schreiben → Tape auswerfen
Damit würden folgende Probleme vermieden:
- keine erneute Auswertung von CreateAt zwischen den Datastores
- kein Wettbewerb um den Drive Lock zwischen zwei Tape-Jobs
- kein unerwartetes zweites Media Set
- kein zusätzliches Tape nur aufgrund einer längeren Wartezeit
- kein ausbleibender Auswurf des ersten Tapes
- keine aufgestauten, unabhängig wartenden Tape-Jobs
- eindeutiger gemeinsamer Status für den gesamten Tape-Sicherungslauf
Fragen
- Ist dieses Verhalten bei PBS 4.2.4 beabsichtigt?
- Wird die Allocation Policy eines wartenden Jobs erneut ausgewertet, wenn der Job tatsächlich den Drive Lock erhält?
- Ist für die CreateAt-Auswertung der geplante Startzeitpunkt oder der tatsächliche Beginn des Tape-Zugriffs maßgeblich?
- Gibt es eine unterstützte Möglichkeit, Job B verbindlich an das von Job A eröffnete Media Set zu koppeln?
- Kann verhindert werden, dass ein bereits seit längerer Zeit wartender Job auf zwischenzeitlich eingetretene CreateAt-Ereignisse reagiert?
- Gibt es eine empfohlene Konfiguration für zwei Datastores, einen Media Pool und ein Standalone-Laufwerk?
- Ist geplant, mehrere Datastores innerhalb eines einzelnen Tape-Backup-Jobs auswählen zu können?
Kurzfassung
Zwei getrennte Tape-Backup-Jobs mit demselben Media Pool und einem Standalone-Laufwerk können dasselbe Media Set und Tape verwenden, wenn beide Jobs innerhalb derselben Allocation-Periode direkt nacheinander laufen.
Wartet der erste Job jedoch über weitere tägliche CreateAt-Zeitpunkte hinweg auf das Tape, kann der zweite bereits wartende Job beim späteren Erhalt des Drive Locks ein neues Media Set eröffnen und ein anderes Tape verlangen.
Die Allocation Policy continue verhindert dieses Verhalten, führt das Media Set aber unerwünscht über mehrere Tage fort.
Die ideale Lösung wäre daher ein einzelner Tape-Backup-Job, in dem mehrere Datastores ausgewählt und sequenziell in dasselbe Media Set geschrieben werden können.
- aber man muss die ganzen Parameter und Prozesse auch erstmal durchdringen.