simples Cloudspeicher-Script für Proxmox vzdumps (inkl. Verschlüsselung)

qiller

Commodore
Registriert
Nov. 2022
Beiträge
4.638
Hu zusammen,

ich suche eine einfache Lösung für folgendes Problem und wollte mal hier im Forum nachfragen, was ihr da so für Lösungen habt oder sogar einsetzt.

Umgebung:
  • Proxmox Host mit paar Windows VMs
  • tägliche lokale vzdumps auf eine große NVMe SSD (kein PBS) mit aktiviertem Pruning (automatische Löschung alter Dumps)
  • 5TB Hetzner Storage Box
  • 300Mbit/s Upload mit Glasfaserleitung der Telekom

Es gibt noch zusätzlich VM interne Sicherungen via Veeam Agent for Windows auf ein NAS. Das soll aber so bleiben und auch nicht in die Cloud gesichert werden, spielt also bei der Betrachtung erstmal keine Rolle.

Gesucht wird ein Script (oder eine andere einfache Cloudspeicher-Lösung) für Proxmox, was folgendes kann:
  • Cloudsicherung der vzdumps, die in den letzten 2 Wochen angelegt wurden, in die Hetzner-Storagebox (webdav/ssh vorhanden, unterstützt wird wohl auch rsync, borg, rclone, scp), keine Unterverzeichnisse o. Versionierung notwendig
  • einfache, symmetrische Verschlüsselung der vzdump-Dateien on-the-fly (dachte da irgendwie an Piping per gpg/openssl? machbar/sinnvoll?)
  • Löschen von vzdumps in der Storagebox, die älter als 2 Wochen sind

Im Grunde sollen immer die vzdumps verschlüsselt in der Storagebox liegen, die nicht älter als 2 Wochen sind. Hab dann überlegt, das als vzdump Hookup-Script oder auch einfachen Cronjob laufen zu lassen.

Was ich nicht will, ist die häufig zu findende Lösung per SMB/CIFS Freigabe in der Hetzner-Storagebox und dann per fstab in Proxmox als Backupspeicher mounten. Erstens krieg ich Kopfschmerzen, wenn SMB durchs Internet geleitet wird und zweitens würde Proxmox dann 2x sichern, einmal lokal, wie bisher und dann nochmal in die Cloud. Verschlüsselung würde da auch erstmal fehlen. Finde ich suboptimal.

Danke schonmal für die Anregungen!
 
Zuletzt bearbeitet:
Bei den SMB/CIFS Mounts bin ich voll bei dir zumal das auch ein gefundenes Fressen für Ransomware wäre.

Schau dir mal rclone genauer an. Du hast es oben schon erwähnt.
Du kannst sehr viele Cloudlösungen (auch SMB/CIFS/FTP...) als Remote einbinden als und hast auch die Möglichkeit zu verschlüsseln (über einen "remote" welcher das an den anderen remote durchleitet). Hier kannst du die Stärke der Verschlüsselung ob mit oder ohne Salt, Ordnernamen und Filenamen alles wie du magst verschlüsseln.
Du kannst das nach und nach selbst erarbeiten, das Tool bietet mit Parametern wie --dry-run eine Testmöglichkeit, was ich besonders beim Löschen von Files (z.b. mit Filter für ein bestimmtes Alter) so auch erst testen würde. Ob du dann copy oder sync verwendest kannst nur du entscheiden.

Was Proxmox angeht bin ich leider nicht im Thema drin.

Ich sichere von unraid auf pcloud verschlüsselt und auf ein weiteres lokales Nas. Es gibt keine gemountete Shares zwischen den Lösungen und jeweils eigene Accounts für die Verbindungen.
 
  • Gefällt mir
Reaktionen: qiller
qiller schrieb:
Cloudsicherung der vzdumps, die in den letzten 2 Wochen angelegt wurden, in die Hetzner-Storagebox (webdav/ssh vorhanden, unterstützt wird wohl auch rsync, borg, rclone, scp), keine Unterverzeichnisse o. Versionierung notwendig

mache ich grob so mit restic (falls versionierung trotzdem ok ist)
Bash:
customer_full_name="qiller cb backups"
customer_alternative_name="qiller"
customer_number="123456"
target_email="logging+backups+123456@example.com"
backup_user="qillerbu"

server_name="pve.example.com"
storagebox_user="u12345678-sub4"

#backup schreiben
0 1 * * * ${backup_user} /usr/bin/restic --repo sftp:${storagebox_user}@${storagebox_user}.your-storagebox.de:/ --password-file /etc/restic/restic-pass backup --files-from-verbatim /etc/restic/backup-list
#backup report versenden
0 2 * * * ${backup_user} /usr/bin/restic --repo sftp:${storagebox_user}@${storagebox_user}.your-storagebox.de:/ --password-file /etc/restic/restic-pass snapshots | mail -s "Papertrail Restic-Backup: ${customer_number} ${customer_full_name} (${customer_alternative_name}) ${server_name}" "${target_email}"


Dann vielleicht noch alles was mehrals 2 wochen alt ist prunen.

repoanlegen und keys ausrollen habe ich sicher irgendwo in der History ^tm
Ergänzung ()


die storagebox grob so - lose an die hetzner doku angelehnt:
Bash:
su ${backup_user}
storagebox_user={u123456-sub4}

mkdir -p /${backup_user}/.ssh/
echo ${storagebox_user}.your-storagebox.de ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA5EB5p/5Hp3hGW1oHok+PIOH9Pbn7cnUiGmUEBrCVjnAw+HrKyN8bYVV0dIGllswYXwkG/+bgiBlE6IVIBAq+JwVWu1Sss3KarHY3OvFJUXZoZyRRg/Gc/+LRCE7lyKpwWQ70dbelGRyyJFH36eNv6ySXoUYtGkwlU5IVaHPApOxe4LHPZa/qhSRbPo2hwoh0orCtgejRebNtW5nlx00DNFgsvn8Svz2cIYLxsPVzKgUxs8Zxsxgn+Q/UvR7uq4AbAhyBMLxv7DjJ1pc7PJocuTno2Rw9uMZi1gkjbnmiOh6TTXIEWbnroyIhwc8555uto9melEUmWNQ+C+PwAK+MPw== >> /${backup_user}/.ssh/known_hosts
ssh-keygen -t rsa -N "" -f /${backup_user}/.ssh/id_rsa # add -C "..." if you want a comment other than root@hostname
ssh-keygen -e -f /${backup_user}/.ssh/id_rsa.pub | grep -v "Comment:" > /${backup_user}/.ssh/id_rsa_rfc.pub
cat /${backup_user}/.ssh/id_rsa*.pub > storagebox_authorized_keys
pwd
echo -e "mkdir .ssh \n chmod 700 .ssh \n put storagebox_authorized_keys .ssh/authorized_keys \n chmod 600 .ssh/authorized_keys" | sftp $storagebox_user@$storagebox_user.your-storagebox.de
rm storagebox_authorized_keys
Ergänzung ()

und repo anlegen
Bash:
sudo restic --repo sftp:${storagebox_user}@${storagebox_user}.your-storagebox.de:/ --password-file /etc/restic/restic-pass init

hab das eben auf dem handy zusammen getackert. Gerade der storagebox einrichten teil ist eher history als fertiges skript. fehler sind zu erwarten, sag dann gern bescheid :D
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: taucher65 und qiller
qiller schrieb:
Erstens krieg ich Kopfschmerzen, wenn SMB durchs Internet geleitet wird
Seit smb3 kann die Verbindung verschlüsselt werden

afaik ist das die option "seal"
 
  • Gefällt mir
Reaktionen: qiller
Erstmal vielen Dank für die Rückmeldung. Ich habe mich jetzt doch für die SMB-Lösung entschieden. Xammu's Hinweis auf die Verschlüsselung von SMB war dann doch nochmal eine Überlegung wert.

Falls jemand mal eine weitestgehend scriptlose Lösung für Proxmox und die Hetzner Storage Box sucht, habe ich mich weitestgehend an diese Anleitung gehalten: https://forum.proxmox.com/threads/w...die-hetzner-storage-box-an.157466/post-723414

Einzige Unterschied war dann die "seal" Option im fstab mount-Befehle:
Code:
//uxxxxxx.your-storagebox.de/backup /mnt/stb cifs iocharset=utf8,seal,rw,credentials=/etc/sbdata.txt,uid=34,gid=34,file_mode=0660,dir_mode=0770 0 0

Den PBS hab ich virtualisiert auf Proxmox installiert, was natürlich suboptimal ist. Der PBS ist aber von den Sicherungen ausgeschlossen, da er hier nur als Vehikel für die Cloudsicherung herhält. Der PBS benötigt auch erstaunlich wenig Ressourcen, 4GB RAM und 2 vCore-Zuweisung reicht völlig - wahrscheinlich auch, weil die Sicherungsgeschwindigkeit von ~40Mbits/s bis 150Mbits/s eher gering, aber für den Sicherungsumfang noch akzeptabel ist. Mit dem PBS sind dann auch verschlüsselte Sicherungen kein Problem mehr.

Da die Sicherungen nur für den absoluten Ernstfall da sind (Bude brennt ab, Hardware wird geklaut...), wird diese auch nur am WE durchgeführt.

Fürs Desaster-Recovery muss dann aber zwangsläufig wieder ein Proxmox PVE und ein Proxmox Backup Server aufgesetzt werden (Bare-metal oder virtuell spielt aber erstmal keine Rolle) und logischerweise der Verschlüsselungs-Key und die Zugangsdaten zur Hetzner Storage Box parat liegen.
 
  • Gefällt mir
Reaktionen: Taderaz
Du hast wahrscheinlich im Zweifelsfall von den Zugangsdaten noch eine Kopie jederzeit bei dir... auf dem Handy. USB Stick oder(und?) Hardprint auf die Bank ginge natürlich auch falls Schliessfach vorhanden oder einfach als zusätzliche Absicherung.
 
  • Gefällt mir
Reaktionen: qiller
Ich würde die Logik rumdrehen. Das Backupziel baut die Verbindung auf und holt sich die Daten. So kann ein kompromittiertes Netz nicht die Cloud Backups löschen.
Klar, eine kompromittierte Cloud könnte dann Zugriff in den Netz erhalten, aber erstmal NUR auf den Zwischenspeicher der verschlüsselten Backups.

Wenn du es verschlüsselt in die Cloud schieben willst, ist duplicati praktisch.
Es kann zwar (afaik) nicht direkt auf proxmox arbeiten, aber eben deine lokalen Backup Daten Verschlüsseln und hochladen.
 
  • Gefällt mir
Reaktionen: madmax2010
Der Proxmox und der PBS sind nicht im normalen Netz erreichbar, die sind über ein extra Netzwerk abgeschottet und da kommt man nur mit Zugriff über die Firewall (VPN) oder physisch per LAN-Stecker rein. Hab mich jetzt auch nicht groß mit der Storage Box von Hetzner beschäftigt. Ka, ob man da überhaupt groß Programme o. Scripte ausführen kann, um ein Pull-Backup zu initiieren.
 
qiller schrieb:
Erstmal vielen Dank für die Rückmeldung. Ich habe mich jetzt doch für die SMB-Lösung entschieden. Xammu's Hinweis auf die Verschlüsselung von SMB war dann doch nochmal eine Überlegung wert.
Eine Transportverschlüsselung erfüllt aber nicht die folgende Anforderung:
qiller schrieb:
Im Grunde sollen immer die vzdumps verschlüsselt in der Storagebox liegen, die nicht älter als 2 Wochen sind. Hab dann überlegt, das als vzdump Hookup-Script oder auch einfachen Cronjob laufen zu lassen.
restic wurde ja schon genannt, ich denke das erfüllt deine Anforderungen am besten. Tipp: Es gibt ein fuse-modul mit dem man das Backup auch mounten kann, vielleicht senkt das die Hürde für dich. Ansonsten gibt es noch deduplizierung und kompression on top.

Aber wenn du unbedingt was mit SMB/CIFS machen willst solltest du allerdings so was in der Art darüber legen, um deine eigene Anforderung zu erfüllen:
https://www.linuxlinks.com/best-free-open-source-encrypted-fuse-based-file-systems/

BTW: Schnell mal was mit openssl crypten: https://docs.openssl.org/3.3/man1/openssl-enc/
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: qiller
foofoobar schrieb:
Eine Transportverschlüsselung erfüllt aber nicht die folgende Anforderung:
Das natürlich richtig, SMB alleine nicht, aber für die Verschlüsselung ist ja der PBS da. Und durch die Geschwindigkeitslimiterung auf den Upload des Internetanschlusses, braucht der auch kaum Ressourcen. Habs mir jetzt 3 Wochen lang angeguckt und läuft wunderbar. Initiale Erstsicherung dauerte 8,5h, die letzte incr. Sicherung am WE ~3h, Garbage Collection 3h, Verification 4,5h. Interessant wirds nochmal, wenn dann die maximale Anzahl an Retentionpoints erreicht wurde. Bin mir da nicht sicher, was PBS da genau macht - ob er da irgendwas merged oder einfach ein neues Vollbackup macht. Mal gucken, erstmal läufts wie gewünscht.
 
qiller schrieb:
Das natürlich richtig, SMB alleine nicht, aber für die Verschlüsselung ist ja der PBS da.
Wenn es da was magisches gibt was deine Anforderungen erfüllt ist ja alles gut.
 
Ja, ist halt die eingebaute Verschlüsselungstechnik im PVE, wenn ein PBS genutzt wird.

Unbenannt.png


Ich finds nur schade, dass über die GUI die Verschlüsselung nur über einen PBS Datastore ermöglicht wird. Daher war ja auch mein Plan, das dann über ein Script "nachzurüsten". Aber die Anforderungen an den PBS sind bei ner Cloud-Sicherung doch schon sehr gemächlich, von daher stört der gar nicht.
 
Achso sry, dachte die Abkürzungen wären bekannt.

PVE = Proxmox Virtual Environment
PBS = Proxmox Backup Server

PVE ist quasi das OS für den Virtualisierungshost und PBS ist ein dedizierter Backupserver speziell für Proxmox Virtualisierungsumgebungen.
 
qiller schrieb:
PVE = Proxmox Virtual Environment
PBS = Proxmox Backup Server

PVE ist quasi das OS für den Virtualisierungshost und PBS ist ein dedizierter Backupserver speziell für Proxmox Virtualisierungsumgebungen.
Aaahhh, Ok. Dann macht PBS die Verschlüsselung, Kompression, Dedup.
 
  • Gefällt mir
Reaktionen: qiller
Ja sry für die Verwirrung.

Ich hatte ja vom Proxmox Backup Server schon gelesen und wusste, was man mit ihm machen kann. Ich wollte es aber vermeiden da noch eine dedizierte Kiste hinzustellen (wie das eigentlich von den Proxmox Machern gedacht ist). Daher ist ja auch der Backup-Storage (8TB NVMe SSD) im normalen VMHost drin und die Sicherungen werden vom VMHost aus angestoßen (neben einer VM internen Sicherung auf ein NAS).

Was ich nicht wusste, war, dass die eingebaute Backup-Funktion im PVE auf Nicht-PBS-Storage keine Verschlüsselung unterstützte und dass der PBS wirklich wenig Ressourcen braucht bei einer Cloudsicherung und auch problemlos virtualisiert laufen kann.

Daher die ursprüngliche Idee mit nem Backup-Hookup Script, was das Verschlüsseln und Hochladen zum Cloudspeicher erledigt. Aber wie gesagt, mit dem PBS erledigt sich das Problem.

Im Desaster-Recoveryfall hat man halt noch den Zwischenschritt mit dem PBS aufsetzen (PVE muss man ja so oder so aufsetzen), egal ob Bare-Metal oder virtuell. Aber so ein PBS aufsetzen geht echt fix, das ist keine Wissenschaft. Und im Idealfall kommt das nie zur Anwendung :x.
 
Zuletzt bearbeitet:
qiller schrieb:
Ja sry für die Verwirrung.
Wer nicht mit Verwirrung umgehen kann sollte besser die Finger von IT lassen :-)

EDV -> Ende der Vernunft :-)
 
  • Gefällt mir
Reaktionen: qiller
Zurück
Oben