Backup Konzept

[KrawallKurt]

Hallo zusammen,
ich spiele seit ein paar Wochen mit Proxmox und habe mittlerweile einige VMs und Container am Laufen, sodass ich mir jetzt so langsam mal Gedanken um Backups mache. Aktuell sieht mein Setup so aus, dass ich eine NVMe für PVE und die VMs/LXCs habe und eine große HDD als Datengrab. Der SATA Controller, an dem die HDD hängt, ist dabei an eine Openmediavault VM durchgereicht.

Meine Idee sieht jetzt folgendermaßen aus:
- Ein zweiter Server, der nur für Backups da ist und per WOL gestartet wird
- rsnapshot auf dem zweiten Server (pull) für die ganzen Daten von der OMV VM
- Backups der Container und VMs ebenfalls auf zweitem Server ablegen

Beim letzten Punkt bin ich mir aber noch nicht so sicher, wie ich das am besten angehe...

1. PBS auf dem remote server installieren und alles direkt dort hin sichern. Geht das vernünftig, auch, wenn der remote server auf HDD sichert? Habe öfter gelesen, dass PBS auf SSD besser funktioniert.
2. SSD vom Hauptserver vergrößern, PBS in einer VM installieren, Backups auf dem Hauptserver ablegen und mittels rsync --delete auf den remote server übertragen. --delete, um nicht unendlich viele Backups aufzubewahren, sondern immer nur den aktuellen Stand je nach retain Regel. Ist eine PBS VM in diesem Fall überhaupt sinnvoll, oder kann man sich das auch sparen?

Danke im voraus!

 

[Dunuin]

PBS auf dem remote server installieren und alles direkt dort hin sichern. Geht das vernünftig, auch, wenn der remote server auf HDD sichert? Habe öfter gelesen, dass PBS auf SSD besser funktioniert.

Hängt von der Menge der Daten ab. Wenn es sich um TBs statt GBs an Backups handelt würde ich keine HDDs nehmen wollen. Da wird der Server sonst ewig laufen, bis da mal die GC- and Verify-Jobs durch sind. Du brauchst halt IOPS Performance. Wenn HDDs dann eh nur als ZFS in Kombination mit SSDs für Metadaten via Special Device oder L2ARC.

SSD vom Hauptserver vergrößern, PBS in einer VM installieren, Backups auf dem Hauptserver ablegen und mittels rsync --delete auf den remote server übertragen. --delete, um nicht unendlich viele Backups aufzubewahren, sondern immer nur den aktuellen Stand je nach retain Regel. Ist eine PBS VM in diesem Fall überhaupt sinnvoll, oder kann man sich das auch sparen?

Sehe ich nicht den Sinn. Ohne lauffähiges PBS kannst du nichts mit den Backups anfangen. Wenn dein PVE ausfällt, dann willst du deinen PBS eigentlich auf einem anderen Rechner weiterhin laufen haben, dass du da schnell PVE neu aufsetzen und Gäste restoren kannst. Ohne da erst noch lange ein neues PBS aufzusetzen und alles an Daten zurückzuschieben zu müssen, bevor du mir dem Restore der Gäste anfangen kannst.
Wenn irgendwann mal das angekündigte Feature der PVE-Host-Backups kommt, dann wäre es auch echt doof, wenn da PBS auf dem selben PVE läuft.

 

[KrawallKurt]

Ohne lauffähiges PBS kannst du nichts mit den Backups anfangen

Ohh, das wusste ich nicht. Dachte, man kann die Backups auch direkt in PVE wieder einspielen, wie die vzdumps. Dann wäre diese Option tatsächlich Blödsinn.

Wenn es sich um TBs statt GBs an Backups handelt würde ich keine HDDs nehmen wollen

Nein, den Großteil der Daten werde ich per rsnapshot sichern und da wird sich meistens nicht so wahnsinnig viel zwischen zwei Backups verändern. Es geht nur um die VMs und LXCs, die sind eher klein. Die Backups werden sicher auch nachts laufen, also nicht so zeitkritisch sein.

Wenn HDDs dann eh nur als ZFS in Kombination mit SSDs für Metadaten via Special Device oder L2ARC.

Wird das dann merklich schneller, als einfach ext4? Gibt es eine Daumenregel, wie groß so eine Cache-SSD sein müsste? Und was wäre besser, Special Device oder L2ARC?


Noch eine weitere Frage: Kann man das Backup der VMs und LXCs auch von Remote triggern? Hintergrund: Falls ich per rsnapshot die Daten von der VM sichere und diese dann gerade auch das Backup macht, gibt es es eine Unterbrechung, oder? Das könnte problematisch sein. Deswegen würde ich gerne eins nach dem anderen machen.

 

[Dunuin]

Wird das dann merklich schneller, als einfach ext4? Gibt es eine Daumenregel, wie groß so eine Cache-SSD sein müsste? Und was wäre besser, Special Device oder L2ARC?

L2ARC kommst du mit einer SSD aus da die verloren gehen darf. Aber auch Null Geschwindigkeitsvorteil wenn du vor hast den Rechner runterzufahren, da der L2ARC dann seine Daten verliert (musst du mal recherchieren ob "persistent L2ARC" inzwischen brauchbar funktioniert).
Special Devices brauchst du im Mirror weil wenn da eine ausfällt sind auch alle Daten auf den HDDs weg. Faustformel war meine ich 0.4% der HDD Größe. Musst du mal hier gucken: https://forum.level1techs.com/t/zfs-metadata-special-device-z/159954

PBS speichert alles als Chunk-Dateien von max 4MB die in der Praxis eher so 1-2MB haben. Heißt hast du 1TB an Backups sind das grob 500.000 - 1.000.000 Dateien und von jeder davon muss beim GC einmal die atime gelesen und geschrieben werden. Wie lange Millionen von Random IO brauchen wenn so ne HDD auf 100 IOPS kommt, kannst du dir ja schnell mal im Kopf überschlagen. Da ist dann nicht viel mit "Kurz mal Backup Server anschalten, schnell inkrementelle Backups und wieder ausschalten".

Noch eine weitere Frage: Kann man das Backup der VMs und LXCs auch von Remote triggern? Hintergrund: Falls ich per rsnapshot die Daten von der VM sichere und diese dann gerade auch das Backup macht, gibt es es eine Unterbrechung, oder? Das könnte problematisch sein. Deswegen würde ich gerne eins nach dem anderen machen.

Dafür gibts ja Snapshot-Mode Backups, dass da die VM weiterlaufen kann ohne heruntergefahren/suspended werden zu müssen. Backups müssen vom PVE Host initialisiert werden. Da müsstest du dann mit der CLI/API vom PVE arbeiten.

 

[KrawallKurt]

Eventuell mache ich auch einfach Voll-Backups und halte eben nicht so viele vor. Das sollte ja problemlos sein, oder? Klar, braucht halt mehr Speicherplatz, aber die Backup Platte einfach eine Nummer größer zu nehmen ist immer noch günstiger, als zusätzliche SSDs.

Nochmal zu meiner Idee 2 von oben

Ohne lauffähiges PBS kannst du nichts mit den Backups anfangen. Wenn dein PVE ausfällt, dann willst du deinen PBS eigentlich auf einem anderen Rechner weiterhin laufen haben, dass du da schnell PVE neu aufsetzen und Gäste restoren kannst.

Hält der PBS eigentlich so eine Art Datenbank, um die Chunks zu Backups zuzuordnen, oder kann der einfach mit den Chunk-Dateien arbeiten, wenn ich die habe? Sprich, müsste ich eigentlich den PBS selbst auch nochmal sichern? Prinzipiell wäre es für mich auch nicht so tragisch, wenn ich zuerst nochmal den PBS installieren müsste. Wie lang dauert das schon? Ich bin nur ein Heimnutzer. Wenn ich alle paar Jahre 1-2h mehr Downtime habe, ist das kein Weltuntergang. Falls der PBS aber nur mit den Dateien nix anfangen kann, wäre natürlich doof.

Vielleicht kriegt der Remote Server aber auch einfach eine HDD für die Daten Backups + eine SSD für die VM/LCX Backups. Das wäre wahrscheinlich eine guter Kompromiss aus Preis und Leistung.

Noch eine Frage zum Speicherbedarf: Brauchen die Backups eigentlich zuerst temporär die volle Größe und dann werden nur die Inkremente gespeichert, oder geht das quasi in-place. Also, wenn ich eine 40GB VM habe und sich zwischen 2 Backups 1GB verändert. Dann brauche ich ja zum Speichern der beiden Backups (mit PBS) nur 41GB Speicher. Aber braucht man während des Erstellens des zweiten Backups temporär 41GB oder nur 1GB?

 

[Dunuin]

Eventuell mache ich auch einfach Voll-Backups und halte eben nicht so viele vor. Das sollte ja problemlos sein, oder? Klar, braucht halt mehr Speicherplatz, aber die Backup Platte einfach eine Nummer größer zu nehmen ist immer noch günstiger, als zusätzliche SSDs.

Bei PBS sind alle Backups sowohl Vollbackups als auch gleichzeitig inkrementelle Backups. Da gibt es keine differenziellen Backups und GC und Verify-Tasks solltest du so oder so laufen lassen. Wenn du das nicht willst müsstest du schon VZDump Backups ohne PBS machen. Und da kannst du dann halt nicht viele Backups je VM behalten.

Mal ein Beispiel was PBS einspart:

Deduplication Factor: 49.17
Original data usage: 4.848 TiB
On-Disk usage: 100.962 GiB (2.03%)

Also meine 4,85 TiBs an Backups von dicken virtuellen Disks verbrauchen nur 101GiB echten Speicherplatz auf dem PBS. Bei VZDump wären das bestimmt 2TiB oder so. Weiß nicht ob das günstiger wäre, wenn ich mir dafür 20x so große HDDs kaufen müsste.

 

[Falk R.]

Zum Thema virtueller PBS. Ich habe meinen PBS virtuell, aber der wird per VZDump auf ein USB Drive gesichert (nur OS Disk) und da kann man viele Versionen aufbewahren, auch wenn man eh nur die letzte braucht.
Der ist im Ernstfall in 2 Minuten auf einem neuen PVE restored und wenn die Backupdisk im System steckt, ist die auch direkt wieder verfügbar.
Somit ist der PBS im Desasterfall auch sehr schnell wieder online.

 

[KrawallKurt]

Deduplication Factor: 49.17
Original data usage: 4.848 TiB
On-Disk usage: 100.962 GiB (2.03%)

Also meine 4,85 TiBs an Backups von dicken virtuellen Disks verbrauchen nur 101GiB echten Speicherplatz auf dem PBS. Bei VZDump wären das bestimmt 2TiB oder so.

Wären es bei VZDump nicht eher die vollen 4,85TiB?

@Falk R. also ist es so, dass auch genau *die* Instanz vom PBS gebraucht wird, mit denen die Backups gemacht wurden und ich nicht einfach PBS neu installieren und die Daten da rein kopieren könnte?

Sind denn die ganzen Chunks als Dateien verfügbar? Also wäre es eine gangbare Lösung, PBS mit seinem Speicher lokal auf der SSD zu haben und dann sämtliche Chunks und ein VZDump der PBS selbst per rsync auf den remote Server mit der langsamen HDD zu schicken?

 

[Dunuin]

Wären es bei VZDump nicht eher die vollen 4,85TiB?

Nein, die "Original data usage: 4.848 TiB" sind ja die dicken virtuellen Disks inkl. Zerodata und ohne Kompression. VZDump kann ja auch Kompression und wenn die virtuelle Disk nur halb voll ist, dann wird VZDump ja auch nicht mehr als den halben Platz verbrauchen um das Archiv anzulegen...eher weniger weil die belegte Häfte sich auch noch mehr oder weniger komprimieren lässt.

@Falk R. also ist es so, dass auch genau *die* Instanz vom PBS gebraucht wird, mit denen die Backups gemacht wurden und ich nicht einfach PBS neu installieren und die Daten da rein kopieren könnte?

Man kann PBS neu aufsetzen und dann den alten Datastore weiternutzen. PBS hat aber keine Option eingebaut einen existierenden Datastore zu importieren. Da musst du manuell Konfig-Dateien editieren. Und dann will so ein PBS auch ordentlich konfiguriert werden mit verschiedensten Usern, Rechten, Jobs, Retentions, Quotas, Monitoring, ... was du dann natürlich auch erst alles erneut konfigurieren musst, damit sich der alte Datastore nutzen lässt.

Sind denn die ganzen Chunks als Dateien verfügbar?

Ja.

Also wäre es eine gangbare Lösung, PBS mit seinem Speicher lokal auf der SSD zu haben und dann sämtliche Chunks und ein VZDump der PBS selbst per rsync auf den remote Server mit der langsamen HDD zu schicken?

Prinzipiell ja, aber ich sehe nicht so den Sinn. Dafür setzt man sich ja eigentlich auf beiden Servern PBS auf und nutzt dann die Sync-Funktion von PBS, um den zweiten PBS die Backups vom ersten PBS pullen zu lassen. Das gibt dir dann auch mehr Schutz und du könntest auch direkt vom zweiten PBS restoren.

 

[KrawallKurt]

Dafür setzt man sich ja eigentlich auf beiden Servern PBS auf und nutzt dann die Sync-Funktion von PBS, um den zweiten PBS die Backups vom ersten PBS pullen zu lassen

Ahh, wieder was gelernt! Und das pullen ist dann schnell, auch über HDD? Oder braucht das auch wieder ne SSD?

 

[Dunuin]

Ahh, wieder was gelernt! Und das pullen ist dann schnell, auch über HDD? Oder braucht das auch wieder ne SSD?

HDD ist nie gut. Der zweite PBS will ja auch regelmäßig das GC und Re-Verify laufen haben. Und das ist ja gerade das, was die HDDs nicht gebacken bekommen.

 

[Falk R.]

Ahh, wieder was gelernt! Und das pullen ist dann schnell, auch über HDD? Oder braucht das auch wieder ne SSD?

Ist nicht optimal aber habe ich bei kleinen Kunden auch so im Einsatz.
Das Verify dauert dann gefühlt ewig, aber da der nix anderes macht außer paar Backups zu holen geht das im kleinen Setup.

 

[KrawallKurt]

Und wäre es für so einen Anwendungsfall nicht auch sinnvoll, einfach den PBS auf dem Host auf der SSD laufen zu lassen und dann die ganzen Chunks und den PBS VZDump per rsync auf den remote server zu ziehen? Dann wäre der ganze IO lastige Kram (nur) auf dem schnellen Host. Warum würde man die IO lastigen Sachen denn sowohl auf dem Host, als auch auf dem Remote Server machen wollen?

 

[Dunuin]

Ransomware-Schutz, Schutz vor unachtsamen Admins, weniger Downtime, Zero-Trust und du musst dem Offsite-Hoster/Admin nicht vertrauen, ...

 

[Falk R.]

Und wäre es für so einen Anwendungsfall nicht auch sinnvoll, einfach den PBS auf dem Host auf der SSD laufen zu lassen und dann die ganzen Chunks und den PBS VZDump per rsync auf den remote server zu ziehen? Dann wäre der ganze IO lastige Kram (nur) auf dem schnellen Host. Warum würde man die IO lastigen Sachen denn sowohl auf dem Host, als auch auf dem Remote Server machen wollen?

Nicht so dolle. Das Verify wird ja nicht umsonst gemacht, wer macht das Verify bei deinen rsync Daten?
Du kannst im Homelab natürlich deinen PBS lokal auf SSD fahren für schnelle VM oder Filerestores und dann für längere Aufbewahrung auf einen zweiten PBS den Sync machen.

 

[KrawallKurt]

Okay, danke für eure Antworten, das hat mir wirklich weitergeholfen. Ich denke, es wird wohl auf einen Server mit HDD für die Daten und SSD für die VM/LXC Backups rauslaufen, also eigentlich ganz ähnlich, wie mein Hauptserver.

Macht es denn Sinn, PBS direkt auf dem Backup Server zu installieren, oder lieber PVE und PBS als VM? Kann ich mit PBS als Betriebssystem auch meine Daten gut auf die HDD sichern, oder sind da irgendwelche Probleme zu erwarten?

Und eine Frage von oben habe ich noch offen. Wisst ihr hierzu, wie sich das verhält?

Brauchen die Backups eigentlich zuerst temporär die volle Größe und dann werden nur die Inkremente gespeichert, oder geht das quasi in-place. Also, wenn ich eine 40GB VM habe und sich zwischen 2 Backups 1GB verändert. Dann brauche ich ja zum Speichern der beiden Backups (mit PBS) nur 41GB Speicher. Aber braucht man während des Erstellens des zweiten Backups temporär 41GB oder nur 1GB?

 

[Dunuin]

Kann ich mit PBS als Betriebssystem auch meine Daten gut auf die HDD sichern, oder sind da irgendwelche Probleme zu erwarten?

Naja, PBS ist halt ein Debian. Machen kann man so gut wie alles, man muss es dann aber halt selbst über die CLI tun. Out-of-the-Box bietet dir da PBS keine Netzwerkfreigaben, rsync oder sonst was.

Noch eine Frage zum Speicherbedarf: Brauchen die Backups eigentlich zuerst temporär die volle Größe und dann werden nur die Inkremente gespeichert, oder geht das quasi in-place. Also, wenn ich eine 40GB VM habe und sich zwischen 2 Backups 1GB verändert. Dann brauche ich ja zum Speichern der beiden Backups (mit PBS) nur 41GB Speicher. Aber braucht man während des Erstellens des zweiten Backups temporär 41GB oder nur 1GB?

Sollte dann nur 1GB brauchen. Du sendest dann ja auch nur die 1GB und PBS macht keine differenziellen Backups und speichert nichts doppelt.
Inkrementelle Backups bauen also nicht auf vorheringen Backups auf.

 

[KrawallKurt]

Ich fasse mal mein Konzept zusammen mit dem ich seit einigen Monaten ganz gut fahre. Am Ende habe ich dann noch eine Frage.

Hauptsystem: PVE, PBS als VM, diverse VMs und LXCs alles auf der NVMe. PBS nutzt hier die Hälfte der NVMe und speichert dort auch direkt die Backups. Eine OpenMediaVault VM (OMV) hat den SATA Controller und daran noch eine Datenplatte hängen, von der einige Verzeichnisse über NFS wieder an PVE zurück und in die LXCs gehen.

Backupsystem: PVE, PBS als VM, OMV als VM alles auf der NVMe. OMV hat den SATA Controller mit einer HDD und einer SSD. Die SSD geht per NFS an den PBS als Speicher, die HDD dient als Backup der HDD vom Hauptsystem mittels BorgBackup.

Über Syncjobs in beide Richtungen können sich die beiden PBS gegenseitig sichern. Eine Sache stört mich allerdings: Wenn ich den PBS vom Hauptsystem auf den PBS vom Backupssystem sichern will, überträgt er alle Backups, die im Haupt-PBS liegen als Teil dieses Backups. Wie kann ich das verhindern? Umgekehrt passiert das nicht. Ich vermute, das ist, weil der Backup-PBS seine Daten auf ein NFS-Store schreibt und der Haupt-PBS die Daten in seine eigene VM schreibt...

 

[Falk R.]

So ganz kann ich dein Problem nicht nachvollziehen. Beim Sync kanst du ja einstellen ob er intial alles Synchronisieren soll und danach wird ja immer das Delta synchronisiert.

 

[KrawallKurt]

Also PBS auf dem Hauptsystem hat einfach eine virtuelle Platte, auf der die ganzen Backups landen. Wenn ich diese PBS VM nun auf den PBS im Backup-System sichere, werden die ganzen Backups, die ja Teil der PBS VM sind nochmal mit übertragen. Wie kann man das vermeiden? Schließlich sind die anderen VMs und LXCs eh schon per sync auf dem Backup PBS gesichert