[SOLVED] NAS als Datastore (Readonly) in PBS einbinden und auf Tape Sichern

[ado]

Liebes Forum,

wir sind letztes jahr von ESXi / Veeam auf Proxmox / PBS umgestiegen.
In Veeam hatte man die Möglichkeit, einen Tapejob anzulegen und direkt eine SMB-Freigabe auf Tapes zu sichern.

Auf dem PBS sind aktuell ca 75TB frei, wir benötigen jedoch ca 180TB, ich habe also nicht genügend platz auf dem PBS um da die Daten zwischen zu speichern.

Nun zur Frage, gibt es eine Möglichkeit, SMB-Freigaben als Datastore zu definieren, aber sehr wichtig, als Readonly?
Der will ja immer die .chunks und .lock anlegen.

Vielleicht kennt jemand noch eine andere Methode um die Daten von einer NAS auf die Tapes zu bekommen.

Ich hoffe, dass diese Infos ausreichen.

Der PBS hat aktuell die Version 3.3.2

Vielen Dank vorab und Gruß

 

[Johannes S]

Vorweg: Ich habe keine praktische Erfahrung mit Tapes, also alles dazu bitte mit Vorsicht genießen

In Veeam hatte man die Möglichkeit, einen Tapejob anzulegen und direkt eine SMB-Freigabe auf Tapes zu sichern.
Auf dem PBS sind aktuell ca 75TB frei, wir benötigen jedoch ca 180TB, ich habe also nicht genügend platz auf dem PBS um da die Daten zwischen zu speichern.
Nun zur Frage, gibt es eine Möglichkeit, SMB-Freigaben als Datastore zu definieren, aber sehr wichtig, als Readonly?
Der will ja immer die .chunks und .lock anlegen.

Korrekt, weil PBS ja den gesicherten Datenbestand ja in zig kleine Dateien (eben die chunks) unterteilt und in den einzelnen Backups nur referenziert (Deduplizierung). Dadurch ist der PBS ja so speichereffezient. Prinzipiell kann man also auch SMB-Freigaben als Datastore (also lesen UND schreiben) nehmen, aber davon wird eigentlich immer abgeraten, weil man damit einfach keine gute Performance bekommt bei den ganzen Chunks:
https://forum.proxmox.com/threads/datastore-performance-tester-for-pbs.148694/

Es macht also keinen Sinn einen Datastore anzulegen, wenn man dort nicht schreiben will, vgl. hierzu auch die Doku:
https://pbs.proxmox.com/docs/technical-overview.html

Was man natürlich schon geht und (z.B. wegen Ransomware Protection) bestehende Datastores read-only einzubinden, um Backups zwischen PBS-Servern zu synchronisieren oder daraus zu restoren.

Das scheint ihr aber so gar nicht zu wollen, oder? Stattdessen wollt ihr die Daten auf der NAS gar nicht mit PBS sichern, sondern nur "irgendwie" aufs Tape kriegen? Das wird nach meinen Verständnis der Dokumentation nicht mit PBS möglich sein, die Tape-Funktion ist dafür da die nativen Datastores vom PBS auf Tapes zu sichern, nicht als Tool um beliebige Daten auf Tapes zu packen:
https://pbs.proxmox.com/docs/tape-backup.html

Dafür müsstet ihr stattdessen spezifische Tools nehmen, die Klassiker in den Bereich wären tar (tape archiver für die Archive) und mt (für Vor-,Zurückspulen etc der Bänder): https://docs.redhat.com/en/document...e-devices#tape-commands_managing-tape-devices

Vielleicht kennen einige der anderen hiesigen Foristen ja noch modernere Tools.

Wie teilen sich die 180TB denn auf? Sind diese Daten alle auf der NAS und sollen gebackupt werden? Als generisches Backuptool wäre PBS nicht meine erste Wahl, sondern eben ein spezfisches. Ob das dann Veeam, bacula, restic, borg oder ganz was anderes ist, ist dann die Frage der Anforderungen und des Budgets Bacula kann zumindestens mit tapes umgehen, nachdem was meine 5 Minuten Google ergeben haben, restic und borg nicht (die sind eher interessant wenn man Cloudspeicher als 2. oder 3. Backupziel nehmen möchte, das Cern hat zwar restic geforkt, um Tapes zu unterstützen, aber soweit mir bekannt ist, gibt es davon nicht den Sourcecode)

Wie sind denn Veeams Backups intern aufgebaut? Ich dachte bisher immer, dass Veeam auch dedupliziert.

 

[ado]

Vorweg: Ich habe keine praktische Erfahrung mit Tapes, also alles dazu bitte mit Vorsicht genießen



Korrekt, weil PBS ja den gesicherten Datenbestand ja in zig kleine Dateien (eben die chunks) unterteilt und in den einzelnen Backups nur referenziert (Deduplizierung). Dadurch ist der PBS ja so speichereffezient. Prinzipiell kann man also auch SMB-Freigaben als Datastore (also lesen UND schreiben) nehmen, aber davon wird eigentlich immer abgeraten, weil man damit einfach keine gute Performance bekommt bei den ganzen Chunks:
https://forum.proxmox.com/threads/datastore-performance-tester-for-pbs.148694/

Es macht also keinen Sinn einen Datastore anzulegen, wenn man dort nicht schreiben will, vgl. hierzu auch die Doku:
https://pbs.proxmox.com/docs/technical-overview.html

Was man natürlich schon geht und (z.B. wegen Ransomware Protection) bestehende Datastores read-only einzubinden, um Backups zwischen PBS-Servern zu synchronisieren oder daraus zu restoren.

Das scheint ihr aber so gar nicht zu wollen, oder? Stattdessen wollt ihr die Daten auf der NAS gar nicht mit PBS sichern, sondern nur "irgendwie" aufs Tape kriegen? Das wird nach meinen Verständnis der Dokumentation nicht mit PBS möglich sein, die Tape-Funktion ist dafür da die nativen Datastores vom PBS auf Tapes zu sichern, nicht als Tool um beliebige Daten auf Tapes zu packen:
https://pbs.proxmox.com/docs/tape-backup.html

Dafür müsstet ihr stattdessen spezifische Tools nehmen, die Klassiker in den Bereich wären tar (tape archiver für die Archive) und mt (für Vor-,Zurückspulen etc der Bänder): https://docs.redhat.com/en/document...e-devices#tape-commands_managing-tape-devices

Vielleicht kennen einige der anderen hiesigen Foristen ja noch modernere Tools.

Wie teilen sich die 180TB denn auf? Sind diese Daten alle auf der NAS und sollen gebackupt werden? Als generisches Backuptool wäre PBS nicht meine erste Wahl, sondern eben ein spezfisches. Ob das dann Veeam, bacula, restic, borg oder ganz was anderes ist, ist dann die Frage der Anforderungen und des Budgets Bacula kann zumindestens mit tapes umgehen, nachdem was meine 5 Minuten Google ergeben haben restic und borg nicht (die sind eher wenn man Cloudspeicher als 2. oder 3. Backupziel nehmen möchte, das Cern hat zwar restic geforkt, um Tapes zu unterstützen, aber soweit mir bekannt ist, gibt es davon nicht den Sourcecode)

Wie sind denn Veeams Backups intern aufgebaut? Ich dachte bisher immer, dass Veeam auch dedupliziert.

Vielen Dank für die Antworten.
Ja, mir ist bewusst, dass das Backup über Netzwerkspeicher keine gute Idee ist, deshalb wir haben es als dedizierten Server mit SSDs und PBS drauf installiert, eingerichtet.
Um mit der Tape Storage sprechen zu können, muss eine spezielle Karte eingebaut werden. Dadurch bin ich an den PBS gebunden.
Bisher habe ich mich fix auf PBS konzentriert, deshalb ich mich noch nicht nach anderen tools umgesehen, danke für die Links und Hinweise.
Weiß nicht, wie aufwändig das handling wird, wir haben eine Tape Storage mit 50 Tapes (LTO7) und einem Roboter, das muss ja alles korrekt angesprochen und gemanaget werden.

Ich werde das mit meinem Kollegen durchsprechen, und auch die noch offenen Fragen beantworten.

 

[ado]

Um die offenen Fragen und unser Ziel besser verständlich zu formulieren, möchte ich kurz unsere aktuelle Situation beschreiben und was das Ziel ist.

Wir haben einen dedizierten PBS mit lokalen SSD und daran via SAS eine Tap-Lib inkl. Roboter.

Der PVE schreibt regelmäßig Backups auf die SSD des PBS. Hier benutzen wir auch die Deduplizierung und diese macht für uns an dieser Stelle auch viel Sinn. Die gesicherten VMs auf Festplatte werden dann auch auf die Tapes geschrieben. Das funktioniert auch alles so, wie es geplant ist. So war das auch in Veeam immer ungesetzt.

Zusätzlich hatten wir in Veeam dann noch einen zusätzlichen Job angelegt.

Dabei wurden mehrere NAS Boxen via SMB im Veeam als Pfad hinterlegt und dann ein eigener Tape-Job angelegt. Dieser hat immer noch volle Backups gemacht (ohne Deduplizierung). Er hat also einfach nach manuellem Start alle eingebundenen SMB Freigaben gelesen und direkt auf Tape geschrieben. Dadurch haben wir keinen Pufferplatz benötigt und konnten unsere NAS Boxen hin und wieder sichern.

Dabei soll der PBS aber keine Datenspuren auf den Freigaben zurücklassen und keine Dateiverwaltung vornehmen, darum auch die Anforderung mit dem read only. Hier noch der Hinweis, es geht hier um ein jährliches Backup.

 

[Johannes S]

Dabei wurden mehrere NAS Boxen via SMB im Veeam als Pfad hinterlegt und dann ein eigener Tape-Job angelegt. Dieser hat immer noch volle Backups gemacht (ohne Deduplizierung). Er hat also einfach nach manuellem Start alle eingebundenen SMB Freigaben gelesen und direkt auf Tape geschrieben. Dadurch haben wir keinen Pufferplatz benötigt und konnten unsere NAS Boxen hin und wieder sichern.

Dabei soll der PBS aber keine Datenspuren auf den Freigaben zurücklassen und keine Dateiverwaltung vornehmen, darum auch die Anforderung mit dem read only. Hier noch der Hinweis, es geht hier um ein jährliches Backup.

Der Usecase ist bei PBS soweit ich weiß nicht vorgesehen (außer jemand aus den Team korrigiert mich), man schreibt die Daten immer erst in einen regulären Datastore, bevor die dann aufs Tape gepackt werden. Sprich: Dafür wäre vermutlich ein daraus ausgelegtes Backupprogramm sinnvoll, welches man dafür nimmt, überlasse ich dann mal den Leuten, die (anders als ich) tatsächlich einschlägige Erfahrung haben.

 

[ado]

Der Usecase ist bei PBS soweit ich weiß nicht vorgesehen (außer jemand aus den Team korrigiert mich), man schreibt die Daten immer erst in einen regulären Datastore, bevor die dann aufs Tape gepackt werden. Sprich: Dafür wäre vermutlich ein daraus ausgelegtes Backupprogramm sinnvoll, welches man dafür nimmt, überlasse ich dann mal den Leuten, die (anders als ich) tatsächlich einschlägige Erfahrung haben.

Vielen Dank für die Anregungen.
Wir werden das jetzt so machen, dass wir ein Backup mit Proxmox-Backup-client einrichten und immer soviel mounten, damit es auf den verfügbaren Speicher des PBS passt.
Mit dem Parameter "--include-dev" den Mountpoint zum Backup hinzufügen, usw. Denke dieser Weg ist dann für uns so i.O.

 

[Johannes S]

Wir werden das jetzt so machen, dass wir ein Backup mit Proxmox-Backup-client einrichten und immer soviel mounten, damit es auf den verfügbaren Speicher des PBS passt.
Mit dem Parameter "--include-dev" den Mountpoint zum Backup hinzufügen, usw. Denke dieser Weg ist dann für uns so i.O.

Ihr mountet also mit dem backup-client das vorherige backup und sichert dass dann mit include-dev ins neue? Wenn das so für euch funktioniert, ist das ein schöner Hack, würde ich aber nicht als Dauerlösung haben wollen

 

[ado]

Ihr mountet also mit dem backup-client das vorherige backup und sichert dass dann mit include-dev ins neue? Wenn das so für euch funktioniert, ist das ein schöner Hack, würde ich aber nicht als Dauerlösung haben wollen

Nein, wir mounten die zu sichernde Freigaben der NAS, und diese sichern wir dann, mithilfe von "include-dev".
Es geht ja in diesem Zusammenhang ja nur um das jährliche Backup. Das ist ja nur eine Notlösung, wir hoffen, dass es vielleicht nächstes Jahr eine andere Möglichkeit dafür gibt.
Die tägliche, wöchentliche und monatliche Backups laufen ja unabhängig davon über den üblichen Weg.