Hi zusammen,
im Zuge eines remote-Backups (also außerhalb des Serverraums, kein Proxmox-Backup-Server) hoffe ich darauf, dass ein NAS den Ansprüchen genügen kann:
Hat jemand Erfahrung oder Ideen, ob QNAP/Synology oder was anderes hier taugt?
VG, Tobias
Hallo Tobias,
wir nutzen schulintern ein paar Synology-Diskstations für Backups. Das funktioniert über NFS problemlos aber das Problem dabei ist, dass es auf diesem Weg natürlich immer Vollbackups sind und die geschriebenen Datenmengen auf diese Weise (unnötig) groß sind. Das macht ZFS und der Proxmox-Backup-Server in Zusammenarbeit natürlich sehr viel eleganter! Da geht es dann entsprechend auch deutlich schneller …
Wenn man also den Punkt „Verschleiß der Platten“ mit in die Rechnung aufnimmt, relativiert sich der günstige Anschaffungspreis der Diskstations wieder etwas, da man auch regelmäßig(er) die Platten erneuern muss…
Viele Grüße,
Michael
Sorry, ich musste einfach schmunzeln… Aber die Kompetenz von BorgBackup ist doch genau, dass es nicht immer Vollbackups sind, oder? Das müsste doch funktionieren…
LG
Max
Ja, aber wir nutzen einfach nur Proxmox und eine Diskstation mit NFS … da läuft kein BorgBackup… (was nicht heißt, dass man das nicht nachrüsten könnte. Aber da ist mir persönlich ein PBS lieber … na ja: am Ende bleibt es Geschmackssache 
)
ah, dass man NFS nutzt und dann (egal was: rsync, rsnapshot, borgbackup) nutzt, darauf bin ich nicht gekommen. Ich ging davon aus, dass ich borgbackup auf dem NAS installieren können muss.
Allerdings hängt sich die Frage an, in welcher Form man die Backup-Daten am besten erstellt, wenn man die Deduplikation von borgbackup nutzen möchte: dann muss ich wohl die komprimierung abstellen, oder hat jemand LZO, ZSTD oder GZIP gegeneinander getestet, ob sich das deduplizieren lässt? Und klappt das mit „ohne“ Komprimierung, weil das ja „tars“ werden.
Ich weiß, vermutlich interessiert das die PBS-Nutzer nicht.
VG, Tobias
Scheint möglich zu sein:
Ja,danke. So was hab ich quasi erhofft.
Nach etwas drüber nachdenken, halte ich das aber nicht für eine langfristige Lösung.
Grund: Ich traue der synocommunity zunächst mal nicht zu, dass sie die manpower + willen hat, das aktuell zu halten. Da kann ich mich grundsätzlich täuschen, zumal die Community ja nur so lange aktiv sein muss, wie mein neu gekauftes Synology ein Lebenszyklus hätte, und es hier nur um ein Werkzeug geht… Aber vorschusslorbeeren und frickeleien sind bei den produktiv-systemen und ihren Backups nicht (immer) angebracht.
Nochmal überlegenswert wäre, wenn das NAS vom Hersteller aktuell bleibt und docker möglich ist und es für borg ein regelmäßiges Dockerfile/docker-image gibt.
Ich würde aber trotzdem auf ein NAS setzen (QNAP, weil Stadt KA das nur will). Auf deren Update-Verlässlichkeit muss ich setzen und die hat zumindest die letzten ~10 Jahre funktioniert (was noch nichts über die Sicherheit der Geräte selbst aussagt, Audits wären eigentlich angebracht aber irgendwo muss ich auch den Cut machen)
Aber dann mache ich es halt wie du: per NFS oder SMB oder SSHFS oder ssh/scp.
Der Vorteil der NAS-Geräte wäre halt die Größe (schnapp dir das und schließe es weg) und der Stromverbrauch und die Weiterverwendbarkeit wenn ein DAU mal meinen Job übernimmt (im Gegensatz zu einem einfachen Linuxdesktop/Intel NUC, den ich dort hinstelle und entsprechend konfiguriere)
VG, Tobias
Hi Tobias,
ja – das sind genau die Gründe, die für ein NAS sprechen … es ist wirklich einfach bedienbar. Wir haben hier auch ein Gerät älterer Generation herumstehen, das aber nicht mehr mit Updates versorgt wird. Da muss man sich dann selbst die Frage stellen, ob man das als „Risiko“ einstuft …
Bei uns stößt das Backup der Nextcloud an seine Grenzen, da dort mittlerweile auch alle Schüler ihre Tablet-Backups ablegen und sich das ganze auf ~ 1TB aufgbebläht hat. Wenn man das in der Nacht jedes Mal als Vollbackup laufen lässt, ist man sehr schnell bei den oben erwähnten langen Backup-Laufzeiten und teilweise unnötigen Schreibvorgängen. Daher will ich mindestens die Nextcloud wieder in einen ZFS-Pool schieben, der dann sehr flott auf einen anderen ZFS-Pool gesichert werden könnte … aber dazu fehlen im Moment die Plattenkapazitäten. Leider sind die Preise für SSDs seit Anfang des Jahres enorm gestiegen. Daher muss die Umsetzung noch warten
Viele Grüße,
Michael
Hi,
auch wenn es nicht ganz passt, sehe ich mich in vielen der genannten Punkten wieder und poste daher einfach mal „unsere“ Lösung:
Für mich relativ nebensächlich war hingegen die Prozessorpower oder gar der Stromverbrauch. Eher „Hauptsache, es läuft“.
Gelandet bin ich dann bei folgender Lösung:
Für mich pragmatisch, funktional und für den Betrieb in der Schule vollkommen ausreichend. Da der Openmediavault-Desktop-Rechner in einem anderen Brandabschnitt als die Server stehen, habe ich ein relativ beruhtiges Gefühl.
Ich werfe diese Lösung mal einfach als Idee in den Raum. Ich freue mich auch gerne über Rückmeldungen / Anmerkungen zu dieser Lösunge
Viele Grüße
Thomas
Danke, @leckelt ,
das ist sicher eine gute Strategie für XCP-ng und so könnte man ähnlich mit Proxmox und PBS argumentieren.
Ich will hier mal noch unsere Backupstrategie Präsentieren und kommentieren und gerne von euch kommentiert haben:
zunächst was in der Schule läuft:
Dann, was bei Hetzner läuft:
und dann etwas Erklärung dazu:
Das sieht ziemlich komplex aus und das finde ich auch. Aber ich finde auch Gründe, warum es so komplex ist:
Meine Frage an euch:
Eine mich interessierende Frage ist, ob Borg denn so sinnvoll von vielen Computern aus ist?
Denn Borg kann nicht von mehreren Computern in dasselbe Repository schreiben. Die Alternative Software „restic“ könnte das. Vor/Nachteile werden hier: https://stickleback.dk/borg-or-restic/ diskutiert. Das bedeutet, dass man pro borg/borgmatic-Installation mind. ein Repo erzeugt, auf das man dann je mit einem repo-key zugreifen kann.
Außerdem muss man sich ja fragen, wie man im Fall eines Crashes oder im Fall eines Umzuges von einem Rechner zum nächsten an die Daten kommt bzw. das Backup nahtlos vom neuen Rechner aus anstößt. Meiner Meinung nach ist das alles kein Problem, solange man den Pfad zum Repo identisch hält und den Encryptionkey hat: Wenn man ein Repo remote ansteuert, kann man das von mehreren Computern tun, aber eben nicht gleichzeitig in ein Repo schreiben.
Zuletzt ist es sehr sinnvoll auf allen Geräten dieselbe borg-installation zu haben. Die ansible-role hier: GitHub - borgbase/ansible-role-borgbackup: Ansible role to set up Borg and Borgmatic ist für mich das Mittel der Wahl. Ich bin allerdings noch unschlüssig, ob ich auf meinem Ziel-NAS von QNAP die „borg-app“ installieren soll (momentan borg 1.4.0), händisch die gewünschte Version via „pip“/„pipx“ oder versuchen soll, oder ob ich ganz auf borg auf dem NAS verzichten soll und via sshfs mein NAS-Ziel mounte.
Hi Tobias,
kurzer Kontext: Wir haben jetzt neu restic im Einsatz, da sich die QNAP mit ARM und borgmatic schwer tut. QNAP und SFTP ist nochmal so ne Sache. Wir mounten einfach den Share mit CIFS und behandeln das wie ein lokales Repo. Für jede VM haben wir einen User auf der QNAP und ein Repo mit jeweils anderem Passwort und Schlüssel. Sollte irgendwo ein Skript hohl drehen ist dann auch nicht alles weg.
Zur eigentlichen Frage: Ich sehe es eher Vorteilhaft, wenn nicht alles ins selbe Repo speichert. Ich erhoffe mir schneller zu finden was ich suche und die Backups leichter „aufgeräumt“ zu halten. Unterschiedliche Server brauchen unterschiedliche Lebensdauern der Backups. Also sind die parallelen Konfigurationen aus meiner Sicht eher ein Feature als ein Problem.
Um das manuelle Skripten kommt man glaube ich eh kaum herum. Nextcloud will z.B. in den Wartungsmodus versetzt werden, bevor man es sichert. Die Ansible-role scheint ja schon viel abzunehmen.
Bei der LMN bietet es sich an, die Samba-Domäne zusätzlich mittels samba-tool domain backup online wegzuschreiben und mitzusichern, um im Notfall schnell wieder ein funktionierendes AD für den Übergang zu haben.
VG, Skye
Hi Tobias,
was spricht denn gegen den (sehr geringen) Aufwand, einen PBS zu installieren? Alois verschenkt gerade PCs (oder ich leih Dir mal wieder einen für immer und ich hab noch ein paar 500GB Platten rumliegen, aber auch 1TB ist nicht mehr teuer… Die Installation geht schnell und dann ist (zumindest in der Schule) alles sehr einfach…
LG
Max
Hi @skye (cooler Name, reimt sich, hihi),
ok. das verstehe ich. Ich habe zwar ein QNAP absichtlich mit AMD64 (neu) gekauft, aber ich hadere mit dem Teil trotzem. Die linux-basis ist ja uralt. Die scheinen irgendwie 10 Jahre alte Linuxe zu verwenden. Kein Wunder ist QNAP und sicherheitslücken ständig in heise zu lesen.
das mache ich jetzt (also nutze zunächst sshfs für mein rsync von Proxmox → QNAP) und das funktioniert mit 100MB/s ziemlich gut an der theoretischen Grenze bei 1GBit/s Anbindung.
Das würde ich intern auch machen. Mit dem externen Server will ich das nur, wenn ich vorher einen wireguard-Tunnel habe (Komplexität !) oder ich mache das von extern eben auch über sshfs.
… und behandle das wie ein lokales Repo. Mal sehn, ob das mit borg auch einigermaßen performant funktioniert.
Danke. Das ist eine überzeugte und überzeugende Meinung! Super.
Für die anderen beiden Hinweise: auch vielen Dank!
Das letztliche Skripten wäre doch für den einen oder anderen interessant, der sich über Backup+Recovery später mal Gedanken machen will.
Ich schau mal, wann ich dann mein Endergebnis veröffentliche und wo.
VG, Tobias
Hi Max,
wie immer: es spricht nichts dagegen. Nur meine Zeit und meine Borniertheit.
du hast vielleicht gesehen, dass ich einen PBS gestrichelt eingebaut habe und ich habe das auch noch vor. Vielleicht mit einer Maschine hier, vielleicht schau ich nochmal, was Alois zu verschenken hat… Und ja, das geht sicher sehr schnell, erfordert aber, dass ich in meinem Serverraum und in meinem Hirn aufräume
Die andere Variante mit borg oder ähnlichem ist wie immer die gemütlichere: ich kann das von zu Hause mit zehn Fingern an der Tastatur lösen…
Ironischerweise muss ich jetzt an die Schule, weil… Stromabschaltung.
Und ich Trottel habe irgendwie die Tage verwechselt und die Stromabschaltung kam einen Tag früher als ich es geplant hatte…
Jetzt habe ich unfreiwillig:
VG, Tobias
Hallo Tobias. Also ich wage mal den Vergleich und wette, dass die Installation eines PBS weniger Zeit gekostet hätte als das Verfassen Deiner letzten beiden Posts inkl. Zeichnung 
Schau Dir einfach das hier an und lasse Dich überzeugen
(Das Video ist von 2020 — dem bin ich damals genau so gefolgt. Natürlich findet man in der Zwischenzeit auch zig andere, aktuellere Videos zum Thema…. die habe ich mir jetzt aber nicht alle extra angeschaut)
Viele Grüße,
Michael
ich zeig dir meinen Serverraum, die Gerippe von Rechnern, die ich überall habe, die möglichen Festplatten für so einen Rechner, den Platz im Schrank, die Konfiguration der Switche, damit der wenigstens mit 1GBit/s angebunden wird…
und dann lasse dich überzeugen, dass ich lieber wieder rückwärts raus gehe
Aber ja: PBS kommt noch.
heute war erstmal Upgrade proxmox 7to8 dran — und hat funktioniert. vorher war eben ein Backup aller virtual-disks nötig und das kostet Zeit bei 1GBit/s und 600 GByte…
LG, Tobias
Hallo Tobias – ja das Phänomen kenne ich auch. Egal, wie gut man einen Serverraum aufräumt – immer wieder läuft der in relativ kurzer Zeit voll mit Elektro-Schrott. Das scheint ja überall gleich zu sein
Aber wenn Du eh schon einen Proxmox-Server hast, kannst Du für den Anfang natürlich auch den PBS einfach mit auf den gleichen Server installieren. Die beiden Webinterfaces werden ja über unterschiedliche Ports angesprochen (PVE → 8006 und PBS → 8007). Das habe ich auf unserem alten Proxmox-Server auch so gemacht. Funktioniert problemlos… In dem Fall musst Du jedenfalls keine alte Hardware bemühen 
Viele Grüße,
Michael
P.S.: Als ein zusätzliches Gimmick des PBS übrigens noch das hier:
Hi nochmal,
hier die ganz spezielle Empfehlung für einen QNAP NAS (modernerer Bauart):
root@nas-vm-debian:/mnt# time sh -c "dd if=/dev/zero of=testfile bs=100k count=100k && sync; rm -f testfile"
102400+0 records in
102400+0 records out
10485760000 bytes (10 GB, 9.8 GiB) copied, 26.4403 s, 397 MB/s
real 0m27.237s
user 0m0.128s
sys 0m23.945s
vs.
[backupuser@NAS backupshare]$ time sh -c "dd if=/dev/zero of=testfile2 bs=100k count=100k && sync; rm -f testfile2"
102400+0 records in
102400+0 records out
10485760000 bytes (9.8GB) copied, 14.292989 seconds, 699.6MB/s
real 0m14.493s
user 0m0.048s
sys 0m11.382s
also ca. 370 MB/s vs. 680 MB/s auf dem nativen System.
cat /etc/network/interfaces
# The primary network interface
auto ens4
iface ens4 inet static
address 10.16.1.124/24
gateway 10.16.1.254
auto ens3.101
iface ens3.101 inet static
vlan-raw-device ens3
address 172.16.17.20/24
#gateway 172.16.17.254
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 172.16.17.254
