Tape Backup Config

[Thoxel]

Hallo zusammen,

wir setzten ein LTO- 7 Drive ein und nutzen 9.50 TiB des Datastores mit einem Deduplication Factor von 19.84. Wir halten 8 Tage an Sicherungen auf dem Store vor.

Jetzt wollen wir täglich auf ein Tape sichern und dies freitags (händisch) durch ein neues ersetzen. Wobei das ersetzte dann natürlich überschrieben werden sollte (Dies ist dann 4 Wochen alt)

Komprimiert schafft LTO-7 15 TB. Daher sollte es ja möglich sein eine Woche abbilden zu können auf einem Tape, wenn inkrementell lediglich ein paar GB pro Sicherung dazukommen und auf dem Tape selbst auch die deduplicated ZFS Datenmenge geschrieben wird.

Welche Config müsste für den Job eingestellt werden?

Wir hatte es mit Allocation --> Continue und Retention --> 7 Tage eingestellt. Ein lief Backup ohne Probleme sobald das aber am nächsten Tag began, erschien der "alloc writable media in pool 'backup' failed: no usable media found" Error

Gleichiges als wir es testweise mit Allocation Continue und Retention Overwrite eingestellt hatten. In beiden Fällen ist die Encryption aktiviert und das Tape hatte sich im Inventory als "Full" markiert.


PBS ist in Version: 2.0-10

Was machen wir falsch bzw was muss für diese Konstellation konfiguriert werden?


Vielen Dank im Vorhinein für eine Antwort.

 

[dcsapak]

bei allocation muss ein wert eingestellt werden, der triggert bevor ihr das neue backup macht, also zb wenn täglich um 18:00 ein tape-job startet, und ihr am freitag ein neues tape eingelegt habt, müsst ihr zb "fri 17:00" bei allocation policy einstellen
dann wird beim job am freitag um 18:00 ein neues media-set angelegt

auch müssen die tapes bereits im vorhinein gelabelt sein.

Komprimiert schafft LTO-7 15 TB.

das is die theoretische maximale kapazität. da die chunks bei uns schon dedupliziert und komprimiert (mit zstd) sind, wird das tape drive sicher nicht nochmal 15TiB auf 6TiB runterkomprimieren können. (ich würde höchstens! mit 10-20% rechnen dh -> maximum 7TiB; muss man aber konkret schauen wie es sich ergibt)

 

[Thoxel]

Wäre bei der Allocation Policy dann auch die täglich inkrementelle Sicherung möglich?

Inwiefern ist in unsere Konstellation die Retention Policy relevant, wenn wir durch den händischen Wechsel die retention als solches sicherstellen? Für die Allocation des Tape würde es ja keine Bewandniss haben, lediglich wenn wir vergessen das Tape zu wechseln?

Kann man denn den Wert sehen oder errechnen, welches nach ZFS Komprimierung und LTO-7 Hardware Komprimierung Netto auf das Tape geschrieben werden kann? Bevor wir in LTO-9 Drives investieren müssen wir sicherstellen, dass es kein Config Fehler oder es ggF. Optimierungen Möglichkeiten gibt bzw. diese Generation dann unsere Datenmenge aufnehmen kann.


Noch eine anderes Anliegen:

Seit Version 2.0-10 vom PBS können wir (als root angemeldet) die Logs von Tape Backup nicht mehr einsehen in der GUI. Wo liegen diese denn? Sieht noch einem chown / chmod Thema aus.

Alle anderen Logs lassen sich ganz normal in der GUI einsehen.

Der Syslog wird bei uns mit Sep 30 12:07:19 pbs-1 proxmox-backup-api[4498]: successful auth for user 'backup@pbs' sekündlich zugespammt. Ist dies normal bzw soll ich das über eine exclude Regel in Syslog rausnehmen?

 

[dcsapak]

Wäre bei der Allocation Policy dann auch die täglich inkrementelle Sicherung möglich?

Inwiefern ist in unsere Konstellation die Retention Policy relevant, wenn wir durch den händischen Wechsel die retention als solches sicherstellen? Für die Allocation des Tape würde es ja keine Bewandniss haben, lediglich wenn wir vergessen das Tape zu wechseln?

ich verstehe die frage nicht ganz

allocation policy bestimmt wann neue media-sets angelegt werden
retention policy bestimmt wann (und ob) alte media-sets ablaufen (und ihre tapes wieder verwendet werden können)
(ist auch hier in der doku ganz gut beschrieben: https://pbs.proxmox.com/docs/tape-backup.html#media-pools)

Kann man denn den Wert sehen oder errechnen, welches nach ZFS Komprimierung und LTO-7 Hardware Komprimierung Netto auf das Tape geschrieben werden kann? Bevor wir in LTO-9 Drives investieren müssen wir sicherstellen, dass es kein Config Fehler oder es ggF. Optimierungen Möglichkeiten gibt bzw. diese Generation dann unsere Datenmenge aufnehmen kann.

das ist im vorhinein leider unmöglich, da man nicht vorhersagen kann wie gut die daten noch komprimierbar sind (ohne sie zu komprimieren) aber im nachhinein müsste das tape drive das sagen können wie viel komprimiert vs unkomprimiert am tape ist

im zweifelsfall würde ich ohne Komprimierung rechnen (komplett zufällige daten sind nicht mehr komprimierbar)

Seit Version 2.0-10 vom PBS können wir (als root angemeldet) die Logs von Tape Backup nicht mehr einsehen in der GUI. Wo liegen diese denn? Sieht noch einem chown / chmod Thema aus.

Alle anderen Logs lassen sich ganz normal in der GUI einsehen.

das ist ein bug, schon behoben im git, aber noch nicht gepackaged, (sollte mit proxmox-backup-server >= 2.0.11-1 gefixt sein)

Der Syslog wird bei uns mit Sep 30 12:07:19 pbs-1 proxmox-backup-api[4498]: successful auth for user 'backup@pbs' sekündlich zugespammt. Ist dies normal bzw soll ich das über eine exclude Regel in Syslog rausnehmen?

das kommt vermutlich von den connections von einem PVE ? jede node versucht alle 10 sekunden sich zu verbinden (um den status abzufragen)

 

[Thoxel]

Hallo Dominik,

nochmals Danke für deine Antworten. Die Allocation und mit Latest-Only sollte soweit funktionieren. Wegen der aktuellen Version kann ich es aber noch nicht sagen, da die Jobs (vermutlich wegen des Bugs) nicht durchgeführt werden (sie laufen tagelang ohne das eine VM im Media Pool gesichert werden).

Könnt ihr bereits antizipieren, wann die gefixte Version (2.0.11-1) bereitsteht?

Bei den zahlreichen PVE würde es den sekündlichen (jede Sekunde) Log Spam erklären. Wird die Meldung in Version 2.0.11-1 dann abgestellt bzw habt ihr das als Topic auf dem Schirm?

Noch weitere Fragen:

1. Gibt es eigentlich einen Alert wie bei Smart, wenn das Tape Wearout einen Schwellenwert (wann ja welcher ist dieser) erreicht hat, damit man dieses ersetzen kann?
2. Falls das Reinigungstape notwendig ist, wird man diesbezüglich dann auch (über den root) via Mail alarmiert?
3. Kann man die Backup Jobs wie z.B. bei einer Firewall Policy hierarchisch anordnen damit ein Job-Datum (systemd.time) zuerst geprüft wird? (z.B. für Ausnahme an Feiertagen)

Vielen Dank im Vorhinein

 

[dcsapak]

Könnt ihr bereits antizipieren, wann die gefixte Version (2.0.11-1) bereitsteht?

nein kann ich noch nicht sagen

Bei den zahlreichen PVE würde es den sekündlichen (jede Sekunde) Log Spam erklären. Wird die Meldung in Version 2.0.11-1 dann abgestellt bzw habt ihr das als Topic auf dem Schirm?

ich glaube mich zu erinnern dass es mal geplant war das ticket zu cachen, siehe https://bugzilla.proxmox.com/show_bug.cgi?id=2903
ein workaround ist, token zu verwenden

1. Gibt es eigentlich einen Alert wie bei Smart, wenn das Tape Wearout einen Schwellenwert (wann ja welcher ist dieser) erreicht hat, damit man dieses ersetzen kann?

nein, sowas gibt es im moment nicht

1. Falls das Reinigungstape notwendig ist, wird man diesbezüglich dann auch (über den root) via Mail alarmiert?

auch das ist nicht implementiert, aber der drive status sollte zeigen falls es notwendig ist

1. Kann man die Backup Jobs wie z.B. bei einer Firewall Policy hierarchisch anordnen damit ein Job-Datum (systemd.time) zuerst geprüft wird? (z.B. für Ausnahme an Feiertagen)

die frage verstehe ich nicht ganz... die jobs haben einen calendar event, einmal pro minute wird geprüft ob dieser seit dem letzen mal fällig wurde.
zb. hat man einen job mit calendar event '01:00' wird dieser täglich ausgeführt
wenn man auch einen hat mit 'sun 02:00' wird dieser nur am sonntag um 02:00 ausgeführt

 

[Thoxel]

z.B. das Tape wird immer Freitags um 2 Uhr morgens ausgeworfen (laut Job), damit es händisch am Freitag Nachmittag gewechselt werden kann. Wenn ich das aber bereits am Donnerstag machen möchte (durch einen extra Job) weil z.B. der 24.12.2021 Weihnachten ein Freitag ist, möchte ich da das Tape ja nicht am nächsten Tag mit dem Standard Job wieder auswerfen, wo es dann keiner austauschen kann.

Eine Option, mit welcher ich den Job aktivieren / deaktivieren könnte, würde dafür ja schon reichen. Dann müsste man für diese speziellen Events nicht die ganzen Jobs umgebaut werden, sondern könnte dedizierte Jobs für diese Wochen im Jahr hinzufügen.

 

[dcsapak]

z.B. das Tape wird immer Freitags um 2 Uhr morgens ausgeworfen (laut Job), damit es händisch am Freitag Nachmittag gewechselt werden kann. Wenn ich das aber bereits am Donnerstag machen möchte (durch einen extra Job) weil z.B. der 24.12.2021 Weihnachten ein Freitag ist, möchte ich da das Tape ja nicht am nächsten Tag mit dem Standard Job wieder auswerfen, wo es dann keiner austauschen kann.

nein, die jobs funktionieren leider nicht so

Eine Option, mit welcher ich den Job aktivieren / deaktivieren könnte, würde dafür ja schon reichen. Dann müsste man für diese speziellen Events nicht die ganzen Jobs umgebaut werden, sondern könnte dedizierte Jobs für diese Wochen im Jahr hinzufügen.

enable/disable von einem job geht im moment indem man einfach den schedule löscht bzw leer lässt, damit wird er nicht mehr automatisch getriggert