Backup Strategie

[christianklaus]

Hi,

ich habe ein kleines Cluster aus zwei Nodes, für die ich bisher noch keine Backups angelegt habe. Es handelt sich nicht um ein Homelab sondern einen Forschungsbetrieb. Ich suche nach Lösungen die aktuell und Best Practice sind. Trotzdem soll das Ganze nicht überdimensioniert sein, sowohl was Technik als auch Kosten angeht.

Ich habe noch keine Erfahrung damit, alles folgende habe ich mir hier und auf reddit angelesen.

Ins Backup sollen die VMs, Container, Messdaten die als Dateien sowie in Datenbanken vorliegen und wenn möglich auch der Host.

Als Onsite-Backup wäre meine erste Idee dass die beiden Nodes sich gegenseitig als Backup dienen. Dafür habe ich in Node1 eine 8TB HDD die ich exklusiv dafür nutzen würde. In Node2 habe ich zwei 20TB HDDs im ZFS Mirror die ich nicht exklusiv dafür nutzen würde (könnte dafür in zwei Storages aufgeteilt werden).

Softwaremäßig tendiere ich zu PBS (jeweils auf Node1 für Backups von Node2 und umgekehrt) und nach diesem Thread dazu das PBS package auf beiden Nodes hinzufügen (PVE und PBS bare metal). Ansonsten in einem LXC.

Als Alternative zum gegenseitigen Backup dachte ich an ein günstiges NAS, sowas wie WD My Cloud EX2 oder Synology DiskStation DS418 mit WD Red Platten (bis 1000 Euro ist für mich deutlich unkomplizierter in der Beschaffung). Haltet ihr das für geeignet für ein professionelles Umfeld oder ist das "zu Consumer"?

Als Offsite Backup wäre mein erster Gedanke die Backups mit rsync in eine Hetzner Storage Box zu schieben oder direkt mithilfe von PBS zu Tuxis.

Eine weitere Möglichkeit wäre die Backup-Dateien mit rclone oder duplicati zu onedrive zu pushen und von dort dann wiederum mit einem Firmenrechner ins Firmennetzwerk runterladen wo sie dann als Backup liegen (gefühlt etwas zu viele Fallstricke).

 

[Dunuin]

ich habe ein kleines Cluster aus zwei Nodes, für die ich bisher noch keine Backups angelegt habe.

Hast du dann ein drittes Gerät als qDevice laufen? Cluster erfordern immer mindestens 3 eigenständige Geräte. Fällt dir sonst einer der beiden Nodes aus, dann verlierst du das Quorum und der andere verweigert ebenfalls den Dienst.

Als Onsite-Backup wäre meine erste Idee dass die beiden Nodes sich gegenseitig als Backup dienen. Dafür habe ich in Node1 eine 8TB HDD die ich exklusiv dafür nutzen würde. In Node2 habe ich zwei 20TB HDDs im ZFS Mirror die ich nicht exklusiv dafür nutzen würde (könnte dafür in zwei Storages aufgeteilt werden).

Ja, das kann man gut machen. Habe hier auf beiden Nodes jeweils ein PBS als LXC laufen (würde ich aber eher als VM laufen lassen wenn ich das nochmal einrichten sollte) damit die sich gegenseitig sichern können. Bei den Datenmengen kommt du bei PBS aber mit HDDs nicht weit. Da sollten es schon besser rein SSDs sein. Oder wengistens HDDs für Daten + SSDs für Metadaten, damit der GC nicht Tage oder Wochen läuft wo die Disks dann zu nichts zu gebrauchen sind weil zu 100% ausgelastet.

Ansonsten in einem LXC.

Läuft im LXC, ist aber nichts was offiziell unterstützt wird. Du weißt also nie, ob dir ein Update nicht vielleicht was zerschießt, da es halt niemand intern vor dem Release testet. Lieber als VM aufsetzen oder Bare Metal neben PVE.

Als Alternative zum gegenseitigen Backup dachte ich an ein günstiges NAS, sowas wie WD My Cloud EX2 oder Synology DiskStation DS418 mit WD Red Platten (bis 1000 Euro ist für mich deutlich unkomplizierter in der Beschaffung). Haltet ihr das für geeignet für ein professionelles Umfeld oder ist das "zu Consumer"?

Da würde ich mir dann lieber gleich einen dritten Server rein für PBS hinstellen anstatt mir da ein fertiges NAS zu holen wo dann die PBS Backups draufsollen. Der könnte dann auch als qDevice dienen und die dritte Stimme abgeben. PBS hat super niedrige Anforderungen was CPU und RAM angeht. Da würde es auch ein alter 100€ Server tun und das gesparte Geld kann man dann lieber in SSDs stecken, weil die HDDs normal als erstes zum Flaschenhals werden. Nicht vergessen: PBS will lokalen SSD Storage wegen den IOPS Anforderungen. Keine HDDs oder NFS/SMB Shares (auch wenn es bei kleinen Datenmengen von unter 2TB gerade noch so geht).

Als Offsite Backup wäre mein erster Gedanke die Backups mit rsync in eine Hetzner Storage Box zu schieben oder direkt mithilfe von PBS zu Tuxis.

Geht beides. Rsync hast du halt den Nachteil, dass wenn du deinen PBS verlierst, du erst ALLES an Daten zurückkopieren musst, bevor du mit dem Wiederherstellen beginnen kannst, da PBS nicht mit einzelnen Backup Archiven arbeitet. Alles ist ein großes Datengemischt aus Millionen über Millionen von kleinen deduplizierten Chunk-Dateien. Beim Offsite PBS könntest du einfach direkt über das Internet deine VMs wiederherstellen.

 

[christianklaus]

Hast du dann ein drittes Gerät als qDevice laufen? Cluster erfordern immer mindestens 3 eigenständige Geräte. Fällt dir sonst einer der beiden Nodes aus, dann verlierst du das Quorum und der andere verweigert ebenfalls den Dienst.

Dieser Problematik war ich mir nicht bewusst. Eigentlich soll node2 node1 auf lange Sicht ersetzen, ich habe das Cluster nur erstellt um VMs und Container zu migrieren. Dieser Prozess ist aber noch nicht abgeschlossen.
Dann sollte ich das Cluster wohl wieder auflösen und hätte dann einfach zwei PVEs im selben Netzwerk.
Oder wäre mein Windows-Laptop ohne PVE auch als qDevice geeignet?

Ja, das kann man gut machen. Habe hier auf beiden Nodes jeweils ein PBS als LXC laufen (würde ich aber eher als VM laufen lassen wenn ich das nochmal einrichten sollte) damit die sich gegenseitig sichern können. Bei den Datenmengen kommt du bei PBS aber mit HDDs nicht weit. Da sollten es schon besser rein SSDs sein. Oder wengistens HDDs für Daten + SSDs für Metadaten, damit der GC nicht Tage oder Wochen läuft wo die Disks dann zu nichts zu gebrauchen sind weil zu 100% ausgelastet.

Dann wäre es wahrscheinlich eher so, dass node1 ausrangiert wird und zum PBS wird. Oder es kommt noch ein günstiger Server + SSDs rein. Habe eben mal einen angeschaut mit 2x 3,84TB 2,5" Micron 5300 PRO Datacenter Enterprise 24/7 Raid SATA SSD 95K IOPS 1,3DWPD, der vom Budget noch passen würde.

 

[Ralli]

Ergänzung zu Dunuin: Ein Quorum brauchst du bei Nutzung der HA-Funktionalität innerhalb des Clusters. Du kannst einen Cluster aus zwei Nodes auch ohne HA und dementsprechend ohne Quorum nutzen - also ohne automatisch wirkende Redundanzen.

 

[Dunuin]

Oder wäre mein Windows-Laptop ohne PVE auch als qDevice geeignet?

Der müsste dann aber 24/7 läufen und immer vor Ort sein. KA ob das mit Windows geht, aber zur Not sicher in einer Hyper-V/Vitualbox VM oder mit Linux Subsystem. Wäre aber viel sinnvoller sich da einfach für 20€ einen gebrauchten Thin-Client oder SBC zu holen.
Siehe https://pve.proxmox.com/wiki/Cluster_Manager#_corosync_external_vote_support für qDevice und Cluster-Anforderungen/Empfehlungen (wie z.B. eigene NIC + Switch rein für Corosync).

Ergänzung zu Dunuin: Ein Quorum brauchst du bei Nutzung der HA-Funktionalität innerhalb des Clusters. Du kannst einen Cluster aus zwei Nodes auch ohne HA und dementsprechend ohne Quorum nutzen - also ohne automatisch wirkende Redundanzen.

Dann schaltet sich aber das PMXCFS auf dem zweiten Rechner auch auf read-only, wenn man den ersten Rechner runterfährt und dann laufen Dinge wie VMs starten nicht mehr.

 

[Ralli]

Ich mag dir nicht widersprechen, du hast mit Sicherheit deutlich mehr Erfahrung als ich.

Allerdings hatte ich über ein paar Wochen einen Cluster ohne HA bestehend aus zwei Nodes laufen und konnte problemlos auf beiden Nodes VMs sowie LXCs starten/stoppen/migrieren usw. - nur eben alles "manuell" und ohne HA. Dabei habe ich auch immer abwechselnd die Nodes gewartet und neu gestartet und konnte dabei auch auf dem verbleibenden Node keine Auffälligkeiten feststellen.

 

[Falk R.]

Ich mag dir nicht widersprechen, du hast mit Sicherheit deutlich mehr Erfahrung als ich.

Allerdings hatte ich über ein paar Wochen einen Cluster ohne HA bestehend aus zwei Nodes laufen und konnte problemlos auf beiden Nodes VMs sowie LXCs starten/stoppen/migrieren usw. - nur eben alles "manuell" und ohne HA. Dabei habe ich auch immer abwechselnd die Nodes gewartet und neu gestartet und konnte dabei auch auf dem verbleibenden Node keine Auffälligkeiten feststellen.

Da muss mal jemand an der Konfiguration gedreht haben und vote auf expected=1 gesetzt. Das aber bitte nur ohne HA.

Zum eigentlichen Thema, ich würde dann lieber einen vernünftigen PVE und einen guten PBS einrichten, als eine Bastellösung.

 

[sb-jw]

Ich kann @Falk R. da nur zustimmen. Ich würde auch kein PVE und PBS mischen oder den in eine VM packen, das gibt nur trouble bei z. B. einem Upgrade, auch wäre das Backup dann nicht ohne weiteres Disaster Recovery fähig und auch nicht gegen Ransomware oder Angriffe auf die Bare Metal Maschine geschützt. Will man sich also Probleme und Risiken ersparen, einfach direkt nen PVE und PBS nebeneinander stellen.

Beim PBS bitte unbedingt mit Tokens arbeiten und diese entsprechend auch einschränken, so dass z. B. vom PVE aus kein Backup gelöscht werden kann (ist auch gar nicht mehr nötig, da der PBS die Löschung anhand der Richtlinie vornimmt).

Aus Erfahrung heraus kann ich zumindest sagen, dass 8x 2 TB 2,5" Drives absolut keine Performance für den PBS bringen. Unser PBS hat nun 6x 960 GB SM883 von Samsung verbaut und knallt die Backups, GC und Verifys ordentlich durch. Ist es auch nur ein Dell PowerEdge R330 mit einer E3-1220 v5 CPU - sowas reicht hier also auf jeden Fall.

Ob du da mit 2x 3,84 TB SSDs wirklich weit kommst musst du mal ausprobieren, ich glaube es ehrlich gesagt fast nicht. Ich würde auch eher zu 4 Disks raten, entweder du machst ein "RAID5" oder ein "RAID10" (* RAID hier eher als Modell, kann auch ZFS etc. sein) daraus. Dann hast du entweder mehr Speicherplatz oder eine höhere Geschwindigkeit.

 

[Dunuin]

Ich kann @Falk R. da nur zustimmen. Ich würde auch kein PVE und PBS mischen oder den in eine VM packen, das gibt nur trouble bei z. B. einem Upgrade, auch wäre das Backup dann nicht ohne weiteres Disaster Recovery fähig und auch nicht gegen Ransomware oder Angriffe auf die Bare Metal Maschine geschützt. Will man sich also Probleme und Risiken ersparen, einfach direkt nen PVE und PBS nebeneinander stellen.

Also hier läuft das so:
PVE A mit PBS A als LXC sichern auf PBS A
PVE B mit PBS B als LXC sichert auf PBS B

PBS A synct zu PBS B
PBS B synct zu PBS A
PBS C Offsite.

Wenn da PVE A warum auch immer ausfällt (Hacker Angriff, Hardware Schaden, Ransomware, Inkompatibilität nach Upgrade) dann ist natürlich auch PBS A nicht mehr lauffähig. Dann habe ich aber immer noch PVE B mit PBS B drauf und kann daraus PVE A + PBS A komplett wiederherstellen (Host Backup von PVE Systemdisks, PVE Konfigs, alle VMs/LXCs, PBS LXC selbst auf dem anderen Server vorhanden). Ransomware Schutz habe ich auch Dank Sync (PVE A kann von PBS B nur wiederherstellen aber nichts sichern/löschen).
Ich habe die beiden PVEs aber nicht im Cluster. Wäre natürlich schlecht, wenn ein Hacker Zugang zu PVE A bekommt und dann Dank Cluster auch gleichzeitig PVE B kontrollieren und den PBS LXC auf PVE B löschen könnte.

Aber ja. Dedizierter Bare Metal PBS lokal + offsite wäre natürlich besser. Fürs Homelab und Co finde ich aber sich gegenseitig sichernde virtuelle PBS schon ein guter Kompromis.

 

[Falk R.]

Ich kann @Falk R. da nur zustimmen. Ich würde auch kein PVE und PBS mischen oder den in eine VM packen, das gibt nur trouble bei z. B. einem Upgrade, auch wäre das Backup dann nicht ohne weiteres Disaster Recovery fähig und auch nicht gegen Ransomware oder Angriffe auf die Bare Metal Maschine geschützt. Will man sich also Probleme und Risiken ersparen, einfach direkt nen PVE und PBS nebeneinander stellen.

Naja nicht ganz richtig. Ich habe meinen PBS auf nem dritten Node als einzige VM am laufen, im notfall könnte man auf dem PVE auch noch etwas restoren. Den PBS sichere ich (das OS) per VZDump auf eine alte NVMe, die ich mit einem USB Adapter angeschlossen habe.
Im Desasterfall kommt der USB an einen neuen PVE und dann restore ich den PBS und hänge die Disk wieder in der VM ein.

 

[sb-jw]

Also im Fehlerfall wollte ich nicht erst mein Backup Server Recovern damit ich meine VMs restoren kann. Man kann Backups ja restoren und direkt laufen lassen, das geht auf Blech dann doch deutlich entspannter, wenn der Server auch wirklich unabhängig ist.

Und bei einem Upgrade habe ich zwei Systeme die ich anfassen muss. Wobei aber der PVE auf dem nur der PBS läuft ja auch unnötige Arbeit wäre.

Mir sind die Backups und meine Zeit zumindest zu wichtig, dass ich hier am falschen Ende spare und mir das Leben schwer mache. Und so wie ich das hier verstanden habe wird auch eine ordentliche Lösung gesucht und keine "kann man so machen, weil ich kein Geld für Backups ausgeben will"-Lösung (no Front).
Ich finde es sehr positiv, dass man hier für Backups auch Geld in die Hand nehmen will. Typischerweise will man ja am besten dafür gar nichts zahlen.

 

[christianklaus]

Vielen Dank für die Diskussion, so far! Daraus kann ich auf jeden Fall einiges mitnehmen. Wie sb-jw schon sagt, sind wir an "ordentlichen Lösungen" interessiert. Nichtsdestotrotz müssen wir uns stellenweise aufgrund begrenzter Ressourcen in Richtung Homelab orientieren, von daher ist auch der Input in diese Richtung für mich wertvoll.
wie du, sb-jw, schon sagtest, haben natürlich auch wir bei der Budgetplanung nicht an Backups gedacht und müssen jetzt schauen, ob wir in anderen Bereichen sparen können.