Umstellung auf remote PBS, bitte um Review

maxim.webster

Active Member
Nov 12, 2024
257
119
43
Germany
So,

nachdem ich jetzt einige Wochen Erfahrung mit Proxmox VE und PBS sammeln konnte, wird es Zeit das Thema Backup zu konsolidieren und auf eine dauerhafte Lösung umzustellen. Ich bitte um Review und Kommentare zu meinem Plan:

In den Backup sollen:
  1. VMs und CTs eines Proxmox VE Clusters (Voll-Backup)
  2. die Nodes des Clusters (File-Backup)
  3. ein weiterer x86 Linux Server (File-Backup)
  4. drei weitere Raspberry Pi Linux Server (File Backup)
Genutzt wird ein Managed PBS Service der Fa. Xaweho, der Preis für bis zu 1TB ist echt fair.

Für die VMs und CTs des Clusters kommt natürlich die in PVE integrierte Backup-Funktion zum Einsatz.
Die File-Backups der anderen Hosts werden über den proxmox-backup-client realisiert, für die Raspberry Pi gibt es keine offizielle Version für arm-CPUs, aber mindestens eine vorkompilierte von Dritten.

Da die Backups extern gelagert werden und mindestens ein Server im Internet steht, kommt Verschlüsselung zum Einsatz. Jede physische Node bekommt einen Encryption Key und der Cluster bekommt einen. So können im Fall einer Kompromittierung eines Servers die Backups zwar gelöscht, aber nicht verändert oder entschlüsselt werden.

Der Backup über den Proxmox Backup Client mache ich (wie jetzt schon) über Cron mit folgendem Script:

Bash:
#!/bin/bash
if [ -f /etc/pve/local/pve-backup.env ] ; then
        source /etc/pve/local/pve-backup.env
else
        exit "File /etc/pve/local/pve-backup.env missing"
fi

/usr/bin/proxmox-backup-client backup root.pxar:/ \
        --crypt-mode encrypt \
        --keyfile /etc/pve/pve-backup.json \
        --exclude /bin \
        --exclude /boot \
        --exclude /dev \
        --exclude /lib \
        --exclude /lib64 \
        --exclude /local-zfs \
        --exclude /lost+found \
        --exclude /mnt \
        --exclude /opt \
        --exclude /proc \
        --exclude /run \
        --exclude /sbin \
        --exclude /sys \
        --exclude /tmp \
        --exclude /usr \
        --exclude /var/lib/lxcfs \
        --include-dev /etc/pve \
        --backup-type host \
        --skip-lost-and-found

/etc/pve/local/pve-backup.env sieht in etwa so aus:

Bash:
export PBS_REPOSITORY=...
export PBS_PASSWORD=...
export PBS_FINGERPRINT=...

und in /etc/pve/pve-backup.json liegt der Encryption Key.

Verteilung des Scripts und der zugehörigen Daten geschieht über Konfigurationsmanagement (ansible), d.h. die Pfade (die aktuell noch auch PVE ausgerichtet sind) können sich ändern. Auch die Liste der Excludes / Includes werde ich dynamisieren, je nach OS und ob der Host ein Docker Host ist oder nicht.

Für den Restore benötige ich dann:
  • den proxmox-backup-client bzw. den aufgesetzten, neuen Cluster
  • den Encryption Key des Clients oder Clusters
  • die Zugangsdaten des PDB Datastores
Fragen:
  • grobe Fehler entdeckt?
  • wurde was vergessen?
  • bringt der Einsatz von Namespaces zusätzliche Sicherheit, in der Art dass die Backups der Server voneinander abgeschottet sind?

Lieben Dank

Maxim
 
  • Like
Reactions: UdoB
bringt der Einsatz von Namespaces zusätzliche Sicherheit, in der Art dass die Backups der Server voneinander abgeschottet sind?
Nein.

Sofern ich alles korrekt verstanden habe: Namespaces sind "künstliche" Gruppen. Die Deduplizierung geschieht "unterhalb", auf Ebene der .chunks.

Wenn ein einzelner Chunk, der in mehreren Backups verwendet wird, verloren geht, sind alle (diese) Backups beschädigt, egal in welchem NS sie liegen.

Wenn man unbedingt mehrere separate Bereiche haben will, muss man mehrere Datastores einrichten. Aber damit verliert man natürlich den größten Vorteil, eben die Deduplizierung...
 
Jede physische Node bekommt einen Encryption Key und der Cluster bekommt einen.

...
  • bringt der Einsatz von Namespaces zusätzliche Sicherheit, in der Art dass die Backups der Server voneinander abgeschottet sind?

Nein.

Sofern ich alles korrekt verstanden habe: Namespaces sind "künstliche" Gruppen. Die Deduplizierung geschieht "unterhalb", auf Ebene der .chunks.

Wenn ein einzelner Chunk, der in mehreren Backups verwendet wird, verloren geht, sind alle (diese) Backups beschädigt, egal in welchem NS sie liegen.

Wenn man unbedingt mehrere separate Bereiche haben will, muss man mehrere Datastores einrichten. Aber damit verliert man natürlich den größten Vorteil, eben die Deduplizierung...
Die Deduplizierung ist eh schon weg, jedenfalls für die Nodes und anderen Clients. Jeder Encryption Key sorgt dafür, dass die Chunks verschieden sind.

D.h. eine weitere Möglichkeit ist, anstatt Datastores verschiedene Encryption Keys zu verwenden. Da muss aber dann auch für jeden Encryption Key einen eigenen Storage im Cluster anlegen. Da helfen dann Namespaces beim Verwalten um die Übersicht zu behalten. Ob das jetzt besser ist als Datastores weiß ich nicht.
Eventuell bei einem Managed PBS wenn ein extra Datastore Kosten verursacht.
 
Die Deduplizierung ist eh schon weg, jedenfalls für die Nodes und anderen Clients. Jeder Encryption Key sorgt dafür, dass die Chunks verschieden sind.
Oh, ja. Da hast du natürlich Recht!
 
Naja man kann den Namespaces aber verschiedene Berechtigungen und api-token zuweisen, das würde ich schon als zusätzliche Absicherung verstehen. Das wird so auch in der PBS Doku im Kapitel zur Ransomware-Protection empfohlen
 
  • Like
Reactions: maxim.webster
Naja man kann den Namespaces aber verschiedene Berechtigungen und api-token zuweisen, das würde ich schon als zusätzliche Absicherung verstehen. Das wird so auch in der PBS Doku im Kapitel zur Ransomware-Protection empfohlen

Guter Hinweis, danke. Aber API Token werden doch auch immer auf einen Benutzer abgebildet, muss ich dann auch mehrere Benutzer anlegen?

EDIT: Sehe gerade die Empfehlung auf https://pbs.proxmox.com/docs/storage.html#restrictive-user-access-management

Configure only minimal permissions for such API tokens. They should only havea single permission that grants the DataStore access role on a very narrowACL path that is restricted to a specific namespace on a specific datastore,for example /datastore/tank/pve-abc-cluster.
 
Last edited:
Guter Hinweis, danke. Aber API Token werden doch auch immer auf einen Benutzer abgebildet, muss ich dann auch mehrere Benutzer anlegen?
Kommt auf den Grad der Paranoia an :) Technisch ist es kein Problem verschiedene Tokens mit unterschiedlichen Permissions für den gleichen User anzulegen
 
Äh, wie jeht denn ditte? Ich hab jetzt ein neues API Token angelegt und versuche mich an der Anlage einer API Token Permission. Aber da wird ein Pfad erwartet und mir wird nur /datastore/<name des datastore> angeboten.

Okay, Frage selbst beantwortet bzw. durch Recherche Antwort ermittelt:

  • der Pfad ist der "root" Pfad zum Datastore (/datastore/<datastore id>)
  • der Benutzername ist <user>@<realm>!<api token name>
  • das Passwort ist der Inhalt des Tokens
  • die Rolle ist Database.Backup und damit kann der Benutzer des Tokens nur Backups seiner eigenen Backup-Gruppe erstellen, verwalten und löschen.
PS: Backups, die vor der Anlage des API Token / der API Token Permission erstellt wurden, müssen über "Change Owner" aus dem Kontextmenü der Backup-Gruppe an den neuen Benutzer (den API Token Nutzer) transferiert werden, sonst ist kein Zugriff möglich.
 
Last edited:
  • Like
Reactions: Johannes S
So,

nachdem ich jetzt einige Wochen Erfahrung mit Proxmox VE und PBS sammeln konnte, wird es Zeit das Thema Backup zu konsolidieren und auf eine dauerhafte Lösung umzustellen. Ich bitte um Review und Kommentare zu meinem Plan:

In den Backup sollen:
  1. VMs und CTs eines Proxmox VE Clusters (Voll-Backup)
  2. die Nodes des Clusters (File-Backup)
  3. ein weiterer x86 Linux Server (File-Backup)
  4. drei weitere Raspberry Pi Linux Server (File Backup)
Genutzt wird ein Managed PBS Service der Fa. Xaweho, der Preis für bis zu 1TB ist echt fair.

Für die VMs und CTs des Clusters kommt natürlich die in PVE integrierte Backup-Funktion zum Einsatz.
Die File-Backups der anderen Hosts werden über den proxmox-backup-client realisiert, für die Raspberry Pi gibt es keine offizielle Version für arm-CPUs, aber mindestens eine vorkompilierte von Dritten.

Auf sowas würde ich mich nicht verlassen wollen, ich würde die ARM-Server also eher mit einen anderen Backupprogramm auf eine eignes dafür verwendete VM sichern, diese dann wieder per PBS offsite oder für die Hosts ein eigenes offsite-Backup. Welches Backuptool man dafür nimmt ist dann natürlich Geschmacksache, ich mag restic (hat mit rest-server auch einen Weg, einen backupserver z.B. in einer VM oder lxc zur Verfügung zu stellen), andere mögen mit kopia oder borg glücklich werden.

Mir wäre es außerdem zu nervig für einen restore eine vergleichsweise langsame Internetverbindung zu nehmen und das offsite-Backup nur als Notfalllösung sehen. Sprich: Ich würde weiterhin eine PBS-VM für schnelle, lokale Restores verwenden. Das hätte auch den Charm, dass man den remote PBS (unbedingt bei Yaweho anfragen, ob die das unterstützen) anweisen könnte sich die Daten per pull-sync vom lokalen PBS zu ziehen. Wenn man die Permissions passend setzt hat man außerdem eine Konstellation, wo selbst bei einer erfolgreichen Ransomware-Attacke im lokalen Netz die offsite-Backups nicht gefährdet sind:

  • PVE-Knoten dürfen Backups auf dem lokalen PBS erzeugen und davon wiederherstellen, diese aber nicht löschen oder bearbeiten
  • Lokaler PBS darf (über die prune/garbage collection jobs) seine eigenen Backups löschen und vom remote PBS pullen, aber keine remote Backups löschen oder bearbeiten
  • Der Remote PBS darf sich die Backups vom lokalen PBS pullen und seine eigenen löschen (wieder prune/gc jobs), aber nicht die Backups auf dem lokalen PBS bearbeiten oder löschen
Siehe dazu auch: https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery

Das setzt natürlich voraus, dass der remote PBS dir die nötigen Rechte gibt, tuxis.nl erlaubt pull-jobs z.B. nur in der Bezahlvariante. Da müsstest du bei deinen Anbieter also mal nachfragen, ob das möglich wäre ;)
Nun brauchst du ja noch ein Backup für deine lokale PBS-VM, dafür nimmst du ein externes USB-Device und sicherst darauf regelmäßig mit der nativen Funktion von ProxmoxVE ohne den Datastore als vma/vzdump-Archiv, so dass du für deren Wiederherstellung KEINEN PBS braucht. Im Wortcase würdest du also erstmal ProxmoxVE installieren, danach die PBS-VM vom USB-Gerät wiederherstellen und anschließend dir dann die ganzen Backups vom remote PBS zurückholen, bevor die wieder in deine Knoten eingespielt werden.

Außerdem zu beachten: Bei der 3-2-1 Strategie will man ja drei Kopien haben, davon mindestens zwei auf verschiedenen Medien. Es wäre also sinnvoll für die lokale PBS-VM z.B. eine externe oder sonstige dezidierte Festplatte als Datastore zu nehmen, damit die Backups vom restlichen System getrennt sind.
 
Auf sowas würde ich mich nicht verlassen wollen, ich würde die ARM-Server also eher mit einen anderen Backupprogramm auf eine eignes dafür verwendete VM sichern, diese dann wieder per PBS offsite oder für die Hosts ein eigenes offsite-Backup. Welches Backuptool man dafür nimmt ist dann natürlich Geschmacksache, ich mag restic (hat mit rest-server auch einen Weg, einen backupserver z.B. in einer VM oder lxc zur Verfügung zu stellen), andere mögen mit kopia oder borg glücklich werden.

Aktuell ist es Borgmatic auf eine Hetzner Storagebox. Die RPIs haben keine Funktion, außer Transceiver für das Homematic-Protokoll zu sein. Alle haben USB Sticks als "Festplatte" auf denen ca. 4GB belegt sind. Die x86 Node, die abseits der Proxmox-Cluster-Nodes zu sichern ist, ist ein externer vServer. Der Aufwand einer weiteren VM als vorübergehendes Backup-Ziel scheint mir nicht angemessen.

Mir wäre es außerdem zu nervig für einen restore eine vergleichsweise langsame Internetverbindung zu nehmen und das offsite-Backup nur als Notfalllösung sehen. Sprich: Ich würde weiterhin eine PBS-VM für schnelle, lokale Restores verwenden.

Die hab ich jetzt auch nicht: Die PBS VM läuft als HA auf einem der beiden Proxmox Nodes. Daher kommt lokaler Speicher an der jeweiligen Nodes nicht infrage. NAS hab ich nicht, darum ist aktuell die Hetzer Storagebox via SMB ins Dateisystem der VM eingebunden und im PBS als Datastore integriert. Stichwort "Langsame Internet-Verbindung": Es handelt sich um Kabel-Internet mit 1000/50, der Download ist also schon flott.

Deine Hinweise sind alle richtig und sehr willkommen, es muss halt die Balance gefunden werden. Die 10 EUR, die ich jetzt pro Monat an Xaweho für das TB Speicherplatz zahle, erlauben mir relativ einfachen und dennoch sicheren Offsite-Backup. Außerdem benötige ich dann keinen lokalen PBS mehr, der - im Falle eines Totalausfalls - erstmal wiederhergestellt werden muss, bevor ich an die eigentlichen Backups komme.

In einem Szenario mit einem lokalen PBS an einem Shared Storage macht Dein Szenario des Syncs wieder mehr Sinn.
 
Aktuell ist es Borgmatic auf eine Hetzner Storagebox. Die RPIs haben keine Funktion, außer Transceiver für das Homematic-Protokoll zu sein. Alle haben USB Sticks als "Festplatte" auf denen ca. 4GB belegt sind. Die x86 Node, die abseits der Proxmox-Cluster-Nodes zu sichern ist, ist ein externer vServer. Der Aufwand einer weiteren VM als vorübergehendes Backup-Ziel scheint mir nicht angemessen.

Jo, dann würde ich es stumpf beim borgmatic-Backup auf die Storagebox belassen. Hat auch den Vorteil, dass du für den restore keinen PBS benötigst ;) Und 4 Euro für 1 TB bei einer Storagebox sollten ja noch im Budget sein, oder?
Die hab ich jetzt auch nicht: Die PBS VM läuft als HA auf einem der beiden Proxmox Nodes. Daher kommt lokaler Speicher an der jeweiligen Nodes nicht infrage. NAS hab ich nicht, darum ist aktuell die Hetzer Storagebox via SMB ins Dateisystem der VM eingebunden und im PBS als Datastore integriert. Stichwort "Langsame Internet-Verbindung": Es handelt sich um Kabel-Internet mit 1000/50, der Download ist also schon flott.

Naja, Storagebox als PBS VM ist tatsächlich keine sonderlich gute Idee: https://forum.proxmox.com/threads/datastore-performance-tester-for-pbs.148694/

Was man schon eher machen kann: Die Storagebox einbinden und dann direkt mit der nativen Funktion von Proxmox darauf sichern. Muss man dann halt früher alte Backups wegschmeißen ;) Kann man auch zusätzlich zum PBS machen, ich sichere meine wichtigsten VMs/LXCs zusätzlich wöchentlich auf die Storagebox (allerdings nicht per CIFS, sondern erst in einen lokalen Ordner und restic schaufelt die dann zur Storagebox) , damit ich notfalls auch ohne funktionierenden PBS noch einen älteren Stand wiederhergestellt kriege.

Was nutzt du denn aktuell als Speicher auf deinen Proxmox-Knoten? Die jeweilige Festplatte/SSD? Eine andere Variante könnte dann je eine PBS VM (oder auch wenn es nicht supported ist als Container) oder PBS-Installation auf den beiden Knoten sein und die sich dann gegenseitig sichern zu lassen.
Damit hättest du dann schon mal zwei Kopien (einmal die laufende VM/LXC im jeweiligen Knoten plus das Backup auf den anderen Knoten).
 
Jo, dann würde ich es stumpf beim borgmatic-Backup auf die Storagebox belassen. Hat auch den Vorteil, dass du für den restore keinen PBS benötigst ;) Und 4 Euro für 1 TB bei einer Storagebox sollten ja noch im Budget sein, oder?

Jo, die 3,81 EUR pro Monat sind schon drin, aber ich hab's gerne einfach. Wenn ich den remote PBS überall nutzen kann, brauche ich die Storagebox nicht mehr. Das gesamte Backup-Volumen hat sich bei ca. 600MB eingependelt.

Was nutzt du denn aktuell als Speicher auf deinen Proxmox-Knoten? Die jeweilige Festplatte/SSD?

Was meinst Du genau? Die PBS VM hat zwar eine Disk, aber der Datastore ist der Storagebox-via-SMB-Mount. Ansonsten hat der Cluster 2 identische Nodes mit jeweils einer kleinen SSD für das OS (und ISO-Images und sowas), sowie jeweils 2 HDD als ZFS Mirror. Dort liegen alle VM und Container Disks drauf.
 
Jo, die 3,81 EUR pro Monat sind schon drin, aber ich hab's gerne einfach. Wenn ich den remote PBS überall nutzen kann, brauche ich die Storagebox nicht mehr. Das gesamte Backup-Volumen hat sich bei ca. 600MB eingependelt.
Naja, dafür hättest du mit der Storagebox dann auch dein Zweitbackup ;) Und wenn du dafür dort deine VMs per vzdump nur wöchentlich reinsicherst, ist immer noch eine zusätzliche Kopie für den Fall der Fälle.

Was meinst Du genau? Die PBS VM hat zwar eine Disk, aber der Datastore ist der Storagebox-via-SMB-Mount. Ansonsten hat der Cluster 2 identische Nodes mit jeweils einer kleinen SSD für das OS (und ISO-Images und sowas), sowie jeweils 2 HDD als ZFS Mirror. Dort liegen alle VM und Container Disks drauf.
Das meinte ich, also wie das Storage vom Cluster aufgebaut ist. Passt das denn von der Performance? HDD wird für VMs und Container eigentlich nicht empfohlen (reiner Datenspeicher ist natürlich was anderes!), aber wenn es reicht, ist ja gut.
Wenn dein Gesamtbackup sich auf 600 MB beläuft, dann müsste es eigentlich passen, dass du auf beiden Knoten dir noch den PBS installierst und dir dann gegenseitig synchronisierst. Benutzt du storage replication für den Cluster, also dass bei einen Ausfall eines Knotens der andere Knoten die VMs/Container starten kann? Dann hast du ja schon immer eine lokale Kopie, was meine obigen Aussagen dann etwas relativiert, auch wenn diese dann kein Ransomwareschutz sind.
 
Storage Replication und High Availability sind an. Jeder Knoten hat genug Ressourcen, um alle VMs und CTs zu betreiben. In erster Linie sind es zwei Rechner, weil sie eben vorhanden waren und so auch mal an einem gebastelt werden kann, ohne das was ausfällt.

Das ist alles im privaten Umfeld, daher muss eben Balance zwischen Kosten (auch Energie) und Zuverlässigkeit herschen.
 
  • Like
Reactions: Johannes S
Wieder weg. Irgendwie .. ich weiß nicht, es ist alles nicht „Mission Critical“, aber ich hab schon bewusst tägliche Backups …