Proxmox Backup Server als LXC auf einem Proxmox Server laufen lassen

[ThomasG8235]

Moin,

ich betreibe daheim einem Proxmox Server. Soweit klappt auch alles. Nun will ich einen zweiten Server aufsetzen. Auf diesem, so war/ist mein Plan, will ich einen Proxmox Backup Server betreiben. Grund dafür ist, dass ich zwar die Vorzüge des PBS nutzen will aber es sich für mich nicht lohnt einen kompletten Server als PBS zu betreiben. Dafür ist es einfach zu wenig Last.

Die Installation ist prinzipiell ja sehr einfach. Ich habe es per LXC gemacht, einfach da ich im Umgang mit LXC geübt bin.

Jetzt aber meine Frage:
Hat jemand ebenfalls einen PBS virtuell als LXC auf einem PVE in Betrieb?
Für mich ist die Konfiguration des Datenspeichers einfach nicht verständlich.
Ich gebe zum Beispiel als Device Passtrough die Platte /dev/sdd komplett für den LXC frei. Allerdings kann ich keinen Datenspeicher für die Backups anlegen.

Mit den Anleitungen via Internet - da werde ich nicht schlau draus.

Kann mir da jemand helfen?

 

[Bu66as]

PBS im LXC läuft grundsätzlich, mach ich bei nem Bekannten auch so. Das Problem ist vermutlich, dass du /dev/sdd als rohes Blockdevice durchreichst, damit kann PBS so direkt nix anfangen, weil der Datastore einen gemounteten Dateisystem-Pfad braucht.

Am einfachsten: die Platte auf dem Host formatieren und mounten, dann per Bind-Mount in den LXC reingeben. Also grob:

mkfs.ext4 /dev/sdd1
mkdir /mnt/pbs-data
mount /dev/sdd1 /mnt/pbs-data

Dann in der LXC-Config (oder übers PVE-Webinterface unter "Resources → Mount Point") nen Mountpoint anlegen, z.B.:

mp0: /mnt/pbs-data,mp=/mnt/datastore

Im PBS-Webinterface dann den Datastore auf /mnt/datastore anlegen, das sollte direkt klappen.

Denk dran, den Mount auf dem Host in /etc/fstab einzutragen, sonst ist er nach nem Reboot weg.

PBS als LXC ist kein offiziell supporteter Weg, funktioniert aber für Homelab-Zwecke problemlos. Falls du mal Probleme beim Updaten kriegst, wär ne kleine VM die Alternative, aber wenn LXC läuft, läuft's.

 

[ThomasG8235]

Vielen Dank für die schnelle und ausführliche Hilfe.
Werde ich gleich mal ausprobieren.

Ja, dass es kein offizieller Weg ist ist mir bewusst, aber für einen kleinen Heimbetrieb soll es ja funktionieren.

Wenn ich nochmal Fragen dazu hab würde ich mich vertrauensvoll nochmal melden.

 

[Impact]

Ich nutze ZFS und gebe dem CT eine (zusätzlich zu rootfs) normale virtuelle Festplatte von dem Speicher. Bind mounts (ohne Workaround) behindern Snapshots und benötigen Rechtemanagement (Stichwort ID Mapping). Da ZFS Platten für CTs datasets/filesystems nutzen komme ich dennoch einfach an die Daten wenn notwendig.
Einfach die physische Platte via node > Disks > ZFS formatieren und noch Thin Provisioning in Datacenter > Storage aktivieren. Dann dem CT via Resources eine virtuelle Platte davon geben und tada.

 

[ivenae]

Ich habe das auch genauso eingesetzt. Erst kürzlich konfiguriert.
- ZFS Volume auf separaten Backup Datenträgern auf dem Host erstellt
- Ordnerpfad via mountpoint (so. Bu66as) durchgereicht (berechtigung beachten)
- LXC mit Debian installiert
- Proxmox APT Quellen eingebunden und installiert

Aus meiner Sicht das am wenigsten "eingewöhnungsbedürftige" Produkt von Proxmox (vergleichen mit VE und MG). Das liegt vermutlich aber nicht an einer durchdachteren Oberfläche, sondern daran, dass das Thema Backup ggü. Virtualisierung und Mailserver verhältnismäßig wenig komplex ist und weniger Stellschrauben hat.

Edit:
Die oben genannte Mountpoint Einbindung erlaubt nicht, dass du einen Snapshot der PBS Maschine erstellst.
Bindest du den Mointpoint wie folgt ein, funktioniert das:

Nicht Snapshot-tauglich:
mp0: /data,mp=/data

Snapshot-tauglich:
lxc.mount.entry: /data data none bind,rw 0 0

 

[Bu66as]

Guter Punkt mit dem lxc.mount.entry, @ivenae. Beim PBS-Datastore willst du den eigentlich gar nicht im Snapshot drin haben, das sind ja deine Backupdaten und schnell mal zig GB/TB. Das "nicht snapshotbar" beim normalen mp0 für die Datastore-Platte ist dann eigentlich praktisch.

Sinnvoll ist eher: rootfs (die kleine PBS-Installation/Config) snapshotbar halten und die Datastore-Platte separat reinziehen, egal ob per lxc.mount.entry oder als eigene ZFS-Disk wie @Impact das macht. Dann snapshottest du den Container ohne die Backupdaten mitzuschleppen.

Beim ZFS-Disk-Weg sparst du dir noch das ID-Mapping-Gefrickel, dafür ist Bind-Mount transparenter wenn du mal von außen direkt an die Daten willst. Beide Wege sauber, am Ende Geschmackssache.

 

[ivenae]

Der extern eingebundene Datenträger ist mit keiner der oben skizzierten Lösungen (mp0, lxc.mount.entry) Bestandteil des Snapshots.

Aber wenn du einen externen Datenträger eingebunden hast, dann funktioniert die Snapshotfunktion bei einer Einbindung via mp0 grundsätzlich nicht mehr, auch nicht für die Hardwarekonfiguration inkl. der root-Partition des LXC.

Bindest du den externen Datenträger mit lxc.mount.entry ein, kannst du einen Snapshot der Root Partition inkl. Hardwarekonfiguration weiterhin anfertigen.

 

[TErxleben]

Mir ist das viel zu wacklig. Ich betreibe PBS auch gerne virtualisiert. Aber da liegt der PBS als VM immer komplett auf einem externen Medium (oder einer internen, dedizierten Platte). Bei der von mir präferierten externen Lösung brauche ich nur mindesten einen weiteren PVE, auf dem die VM-Konfiguration hinterlegt ist. So ziehe ich ein 20TB-Datengrab innerhalb von 2min auf eine andere PVE-Basis um.

PBS als LXC? Im Leben nicht!

USB-C oder Thunderbold ist inzwischen rattenschnell. Limitierender Faktor ist das Speichermedium.

Wozu ich fancy snapshots o.ä. in einem versionierenden Mechanismus wie PBS brauchen könnte, konnte mir noch keiner erklären.
Wichtig ist alleine, wie gut gekapselt und damit schnell und reibungslos ein Rettungsanker wieder an den Start zu bringen ist.

 

[Bu66as]

Klar, das Snapshotten der Datastore-Platte ist Quatsch, da sind wir uns einig, PBS versioniert die Backups ja selbst. Bei der kleinen rootfs/Config gehts mir aber nicht um die Backupdaten, sondern darum nach nem verkorksten PBS-Update oder ner Config-Änderung schnell zurückrollen zu können. Das hat mit der Backup-Versionierung nix zu tun, ist nur fürs Appliance-OS selbst.

Dein VM-auf-externem-Medium-Weg ist aber genauso gut, gerade die Portabilität (20TB in 2min auf ne andere Basis ziehen) ist ein echtes Plus. Am Ende Geschmackssache, wie gekapselt und schnell umziehbar man den ganzen Kram haben will.

 

[Johannes S]

Gegen PBS als lxc spricht halt vor allen, dass der Weg nicht offiziell vorgesehen und (soweit ich weiß) auch nicht supported oder getestet wird. Wenn jemand von Team dem widerspricht, werde ich aber sicher nicht verärgert darüber sein Damit wäre das für mich ein no-go im Unternehmenseinsatz, wobei ich da strenggenommen auch eine VM schon grenzwertig finde, der Restore eines Backups sollte nicht von der Funktionsfähigkeit eines Hypervisors abhängen

Im Homelab hat ein PBS-LXC in Vergleich zu einer VM oder einer Paaralelinstallation zu ProxmoxVE aber schon ein paar Vorteile: Man verschenkt keine Performance (wie bei einer VM, ein zfs dataset durchzureichen hat eine DEUTLICH bessere Performance als virtiofs, ISCSI/NFS/smb würde zwar auch gehen, aber dafür muss man dann einen Dienst auf den Host laufen lassen und hat außerdem wieder mehr= Overhead) und man kann den PBS unabhängig vom ProxmoxBackupServer aktualisieren (sobald eines der beiden auf ein neues Debian-Release gehoben wird, will man ja envtl. nicht warten bis das neue Release vom anderen vorhanden ist). Ich selbst mache es mittlerweile so (nachdem ich erst PBS-VMs mit einen iscsi-Datastore, später dann virtiofs am Laufen hatte): Direkt auf meinen Haupt-ProxmoxVE-Server läuft ein PBS in einen lxc, der hat keine andere Funktion als Backups als Zwischenstation entgegen zu nehmen. Mein eigentlicher ProxmoxBackupServer (alter Mini-PC mit ProxmoxBackupServer als Hauptzweck und ProxmoxVE paarlel installiert, falls ich mal ein Notfallsystem brauche ) wird jede Nacht automatisch geweckt und zieht sich dann die neuen Backup vom PBS-LXC (per pull-sync) . Ebenfalls über Nacht zieht sich mein offsite-PBS (auf einen vserver bei netcup) auch die neuesten Backups vom pbs-lxc. Mit anderen Worten: Ich sehe das PBS-LXC nicht als Backup in Sinne der 3-2-1-Regel ( https://pbs.proxmox.com/docs/storage.html#the-3-2-1-rule-with-proxmox-backup-server ), sondern als Zwischenstation zum eigentlichen Backup und um schnell was restoren zu können, ohne den Mini-PC starten oder den (langsamer angebundenen) offsite-vserver nutzen zu müssen.

 

[TErxleben]

Klar, das Snapshotten der Datastore-Platte ist Quatsch, da sind wir uns einig, PBS versioniert die Backups ja selbst. Bei der kleinen rootfs/Config gehts mir aber nicht um die Backupdaten, sondern darum nach nem verkorksten PBS-Update oder ner Config-Änderung schnell zurückrollen zu können. Das hat mit der Backup-Versionierung nix zu tun, ist nur fürs Appliance-OS selbst.

Dein VM-auf-externem-Medium-Weg ist aber genauso gut, gerade die Portabilität (20TB in 2min auf ne andere Basis ziehen) ist ein echtes Plus. Am Ende Geschmackssache, wie gekapselt und schnell umziehbar man den ganzen Kram haben will.

Davon abgesehen, dass es immer mindestens einen pull-Server gibt, ist in meinen Augen der Ausfall der Sicherungsplatten-HW das größte Risiko. Wenn ich Langzeit-Archivierung wünsche, dann gibt es eben einen Pull-service, der das liefert. Darauf greife ich aber i.d.R. nie zurück (und bete drum es nie tun zu müssen).
Plötzlicher HD-Tod ist mir in 45J sehr selten passiert. Wenn es doch passiert, muss ich eben die Daten vom
pull-Server organisieren und den StandardPBS neu aufsetzen.

Mir hat bisher (und ich bin lange dabei) noch kein PVE/PBS-Update fies in die Suppe gespuckt.
Wie du anführst, muss das jeder aber selbst abwägen.

 

[TErxleben]

Gegen PBS als lxc spricht halt vor allen, dass der Weg nicht offiziell vorgesehen und (soweit ich weiß) auch nicht supported oder getestet wird. Wenn jemand von Team dem widerspricht, werde ich aber sicher nicht verärgert darüber sein Damit wäre das für mich ein no-go im Unternehmenseinsatz, wobei ich da strenggenommen auch eine VM schon grenzwertig finde, der Restore eines Backups sollte nicht von der Funktionsfähigkeit eines Hypervisors abhängen

Was gewinnst du ohne HV ggü. einer reinen HW-Lösung?

Im Homelab hat ein PBS-LXC in Vergleich zu einer VM oder einer Paaralelinstallation zu ProxmoxVE aber schon ein paar Vorteile: Man verschenkt keine Performance (wie bei einer VM, ein zfs dataset durchzureichen hat eine DEUTLICH bessere Performance als virtiofs, ISCSI/NFS/smb würde zwar auch gehen, aber dafür muss man dann einen Dienst auf den Host laufen lassen und hat außerdem wieder mehr= Overhead) und man kann den PBS unabhängig vom ProxmoxBackupServer aktualisieren (sobald eines der beiden auf ein neues Debian-Release gehoben wird, will man ja envtl. nicht warten bis das neue Release vom anderen vorhanden ist).

Darum sage ich ja VM statt LXC. die deutlich bessere Performance sehe ich auch überhaupt nicht.

Habe ich einen rattenschnellen zentralen Speicher angebunden, verschiebe ich die Gefahr des Ausfalls einer popeligen USB-Platte nur auf dieses Medium. Selbiges ist aber seltenst gottgegeben und will korrekt administriert werden.
Da finde ich den Plan, wie eine VM wieder schnell am Start ist, besser. Um ein RAID zu "emulieren", setze ich sogar zwei PBS parallel ein. Die doppelte Sicherungszeit ist in meinem Umfeld vernachlässigbar.

 

[Johannes S]

Was gewinnst du ohne HV ggü. einer reinen HW-Lösung?

Dass wenn der Hypervisor aus welchen Grund auch immer über den Jordan geht ich immer noch funktionierende Backups habe.

Zur Performance: Glaube es oder glaube es nicht, aber das per bind mount durchgereichte zfs dataset hat deutlich kürzere verify und garbage-collection Zeiten als vorher das gleiche Dataset per virtiofs.