BackUps über VPN per cronjob

[R.Kante]

Moin,

folgende Situation:
Vor mir steht seit Kurzem ein Zyxel NSA325v2 bestückt mit 2x2TB. Seit Frühjahr steht bei meinem Vater, einige Kilometer entfernt, ein alter Desktop-PC mit einem 2TB RAID1. OMV als OS, darauf betreibe ich eine Nextcloud-Instanz, innerhalb eines Docker-Containers, die wir innerhalb der Familie nutzen. Eine Zeit lang habe ich Daten aus den Nextcloud Benutzer-Ordnern via FritzBox zu FritzBox VPN und rsync-cronjob täglich auf eine an meiner Fritz-Box angeschlossene Externe HDD gesichert. Die Platte wiederum war als SMB Laufwerk im OMV eingebunden. Da diese Platte absehbar zu klein war und ich bei mir Zuhause ohnehin gerne einen größeren, lokalen und internetunabhängigen Netzwerkspeicher haben wollte, steht hier nun das genannte NAS.

Jetzt stellt sich mir die Frage nach der richtigen Übertragungsart. Das oben genannte Prozedere habe ich eher intuitiv eingerichtet, weil es mir sinnvoll und einfach erschien. Hin und wieder, keine Regelmäßigkeit erkennbar, habe ich aber vom OMV eine CPU-Load Warnung bekommen, wenn der rsync-cronjob ausgeführt wurde. Nur die Benutzerdateien zu sichern erscheint mir aus jetziger Sicht auch etwas unvollständig. Über die Performance kann ich keine Aussage treffen, das Ganze fand täglich ab 01:00 Uhr statt und war einfach irgendwann fertig, bevor es mich stören könnte. Meine Hoffnung ist nun, dass ich mit dem richtigen Übertragungsprotokoll und dem richtigen sync-cronjob oder Programm, eine gleiche Funktion hinbekommen, nur eben ohne Fehlermeldungen. Also in regelmäßigen Zyklen ein BackUp der Nextcloud inkl. Datenbank nach Schema F auf das hiesige NAS.

Habt ihr da Empfehlungen? Nutzt man in so einem Fall lieber FTP und spart sich damit die Einbindung als Laufwerk?

Beste Grüße und Vielen Dank im Voraus.

 

[TroubleshQQter]

entweder skripte, die die sql db dumpen + alle ordner aus dem webserver directory, das geserved wird, sowie kopie des nextcloud-data ordners (=benutzerdaten, aber die sicherst du ja jetzt schon). einfacher wäre ein kompletter snapshot der vm/des containers und diesen dann exportieren auf dein usb laufwerk. ich bin mir aber unsicher, ob omv das kann, ich hatte mal nextcloud als test als plugin unter freenas installiert, aktuell betreibe ich drei nextcloud Instanzen auf nem kvm hypervisor. dort ist ein nächtliches backup via snapshot auf ein remote target meine momentane vorgehensweise.
sorry 4 Rechtschreibung - Smartphone...

 

[snaxilian]

@R.Kante Kennst du das Sprichwort: "Ein Bild sagt mehr als tausend Worte." und erwartest du ernsthaft, dass hier jeder aus deiner klassischen Textaufgabe sich alles zusammen suchen?
Hinzu kommt, dass du mal beschreibst wo ein Gerät mal irgendwo stand aber du es jetzt woanders hin geholt hast? Wen interessiert was einmal war wenn du Fragen zur jetzigen Situation hast? Das macht es nicht wirklich übersichtlicher.
Viel heiße Luft aber ich lese daraus:

• In deinem Netzwerk zuhause steht ein Zyxel NAS
• in einem entfernten Netzwerk steht ein Openmediavault wo irgendwie (am WebUI vorbei? Per Docker? Per OMV Plugin?) eine Nextcloud installiert ist
• Du willst jetzt regelmäßig und automatisiert Backups der Nextcloud erstellen und diese auf dem Zyxel NAS ablegen.
• Deine eigentliche Frage ist jetzt die Art der Übertragung.

Was bringt es dir jetzt, wenn wir dir irgendwelche super-optimierten und perfekten Übertragungsprotokolle nennen und empfehlen aber dein NAS diese gar nicht unterstützt? Da ich es nicht als meine Aufgabe ansehe die verfügbaren Protokolle zu suchen gehe ich von dem Offensichtlichen aus, ergo SMB und vielleicht noch NFS. Beide haben nur in den neuesten Versionen eine Verschlüsselung, also hoffe ich inständig, dass du mit "Box zu Box VPN" ein Site-to-Site VPN zwischen Fritzbox bei dir und im entfernten Netzwerk meinst.
Ob du jetzt NFS oder SMB nimmst macht keinen großen Unterschied meiner Meinung nach. Ich würde das in deinem Fall mit einem kleinen Script erledigen:

Mount des zyxel-nas;
Prüfung ob der Mount erfolgreich war. Falls nein > Alert & Ende;
Maintenance-Mode setzen und auf Erfolg prüfen;
Dump der mysql/mariadb;
Verschieben/rsync der Nutzdaten sowie des sql-Dumps auf den Share;
Maintenance-Mode beenden und auf Erfolg prüfen;
Unmount des zyxel-nas;

Du solltest dich natürlich mit Rsync beschäftigen denn ohne groß weitere Daten anzugeben hält es zwei Verzeichnisse synchron. Was dir somit noch fehlt ist eine Art Versionierung falls gewünscht. Aber auch das lässt sich umsetzen. Eine Suchmaschine und "rsync versioning backup" sollte einige brauchbare Ansätze liefern.

 

[R.Kante]

Da ich eine Frage (implizit) gestellt habe, die sich auf die jetzige wie die vorherige Situation bezieht, ist die Beschreibung der vorherigen Situation obligatorisch. Auf die Gefahr hin mich zu wiederholen, in der alten Konstellation:

• Nextcloud im Docker-Container
• FritzNAS mit SMB über fstab eingebunden
• Tägliche Ausführung von rsync zum Sichern der NC-Benutzerdateien auf FritzNAS
• OS: OMV 5.5.14-1
• Verbunden über FritzBox 1 per VPN zu FritzBox 2
• An FritzBox 2 hängt eine HDD als FritzNAS

Kam es unregelmäßig zu CPU Load Warnungen, die mir OMV per Mail gesendet hat. Hierzu ein Auszug der Mail:

Event: Resource limit succeeded
Description: loadavg (5min) check succeeded [current loadavg (5min) = 3.0]

Der Befehl der in der alten Konstellation täglich ausgeführt wurde:

rsync -a --no-o --no-g --bwlimit=400 /Pfad_NC_files /Pfad_FritzNAS_Mount

--no-o und --no-g habe ich meiner Erinnerung nach genutzt, weil es beim Zugriff auf das FritzNAS von bsw. meinem Rechner zu Problemen kam. In Zukunft plane ich dann den Befehl entsprechend der NC-Backup-Anleitung zu nutzen.

Die implizite Frage ist nun, ob ich die genannte Warnung bei verändertem Ziel mit gleicher Einbindung ebenfalls erwarten kann. Weiterführend wäre natürlich interessant ob ich mir darüber Gedanken machen sollte und wenn ja, wo am besten mit der Fehlersuche begonnen werden sollte.

Die neue Konstellation gleicht der Obigen größtenteils:

• Nextcloud im Docker-Container
• ZyxelNAS Einbindung noch unklar
• Regelmäßige Ausführung von rsync zum Sichern der NC (Datenbank u. Nutzerdateien)
• OS: OMV 5.5.14-1
• Verbunden über FritzBox 1 per VPN zu FritzBox 2
• ZyxelNAS per LAN mit FritzBox 2 verbunden

Wie dem aufmerksamen Leser bereits aufgefallen sein dürfte, ist mir grundlegend unklar, welche Art von Einbindung hier am sinnvollsten ist, oder was in diesem Fall am üblichsten ist. SMB, NFS, FTP - die drei fallen mir spontan ein und für diese bekäme ich auch eine Einbindung hin. Nun kommt noch aus Post #3 der Vorschlag die Einbindung nur für den sync-Vorgang zu nutzen. Welche Vor- und Nachteile hat das gegenüber einer dauerhaften Einbindung?

Falls das manch einem in diesem Forum zu viel Text ist oder ich mich zu undeutlich ausgedrückt habe, bitte ich das zu entschuldigen und entsprechende Nachfragen zu stellen. Ebenso natürlich, wenn entscheidende Informationen fehlen. Ein bisschen Leseverständnis erwarte ich dann aber doch. Im Obigen Post habe ich zwei Informationen hinzugefügt.

Beste Grüße und vielen Dank im Voraus!

 

[snaxilian]

Dauerhafte Einbindung bedeutet, dass du immer davon ausgehst, dass an beiden Standorten Internet verfügbar ist und der VPN Tunnel immer funktioniert. Ist dies nicht der Fall und du schreibst dann in einen Pfad der lokal ist weil die Freigabe nicht klappt dann schreibst dir das lokale Dateisystem voll. Außerdem hätte auch ein Virus etc. dauerhaft Zugriff aufs Backupverzeichnis.

Die von dir verlinkte "Schema F" Anleitung bezieht sich auf klassische Nextcloud-Installation, bei einer gedockerten Instanz reicht es theoretisch, das Volume zu kopieren sofern alle wichtigen Daten in einem Volume sind.
Das 1:1 unangepasste abarbeiten eines Schema F funktioniert halt nur wenn auch alles andere nach Schema F ist. Ergo Installation direkt auf einem OS nach der Doku und nicht als Docker in einer "Appliance" wie OMV. Dann musst du natürlich das Vorgehen soweit an deine Situation anpassen.

Sich mühselig alle Infos aus einem Fließtext raus ziehen bei dem die Hälfte irrelevant ist weil es irgendwas beschreibt was es mal gab aber so nicht mehr existiert und Leseverständnis sind zwei unterschiedliche Dinge

 

[R.Kante]

So sieht bisher mein Script-Entwurf für temporäre Einbindung als SMB/CIFS aus, ein paar Sachen sind für die Übersichtlichkeit rausgekürzt:

#!/bin/bash

mount -t cifs //192.168.142.41/nextcloud_bkp -o vers=1.0,username=nm,password=pw /.../kniebox1

if mount | grep /srv/dev-disk-by-label-RAIDstorage/kniebox1; then
    docker exec --user www-data nextcloudpi php occ maintenance:mode --on
    docker exec nextcloudpi mysqldump --replace -u nm -p pw nextcloud > /.../kniebox1/dump.sql
    rsync -Aavx --bwlimit=400 --delete-after /.../nextcloud/ /.../kniebox1/
    docker exec --user www-data nextcloudpi php occ maintenance:mode --off
    echo "backup fertig";
    umount /srv/dev-disk-by-label-RAIDstorage/kniebox1
else
    exit 1
fi

Die docker exec Befehle habe ich bei einigen früheren Versuchen bereits erfolgreich getestet. Neu ist allerdings die Option --replace für mysqldump, bzw. --delete-after für rsync. Meine Intention ist es vorerst keine Versionierung vorzunehmen und das einmal geschriebene Backup entsprechend der Quelle zu aktualisieren, sowohl bei der Datenbank als auch bei den Nutzerdaten.
@snaxilian, meinst du die gewälten Befehle und Optionen eignen sich für diese Intention?

 

[snaxilian]

Eine Frage vorab: Verwendest du NextcloudPi?

Spoiler: Falls ja:

Du liest zwar meine Worte aber verstehst sie offenbar nicht. Welchen Teil von

Dann musst du natürlich das Vorgehen soweit an deine Situation anpassen.

hast du nicht verstanden? In der Doku von nextcloudpi finden sich Tipps und Anleitungen wie man davon vollständige Backups erstellt. Ich persönlich halte von der gedockerten Nextcloudpi sehr wenig, da es viele Paradigmen von der Art und Weise wie Docker funktioniert und was die Vorteile davon sind gnadenlos ignoriert und über Bord wirft und dafür Komplexität für den Anwender versteckt. Für private Setups geeignet aber alle Anpassungen "drum herum" müssen dann diese Anpassungen und Eigenheiten beachten was es wiederum schwieriger machen kann.

Falls nein: Ich würde nicht nur die Tabellen/Datenbanken exportieren auf die der DB-User nm berechtigt ist. Denn auch die User einer mariadb/mysql stehen in Tabellen und deren Berechtigungen etc. ebenso. Für den Fall einer Wiederherstellung müsstest also zuerst die gewohnte Umgebung wieder herstellen und dann die Daten zurück spielen. Setzt voraus, dass dann nextcloudpi noch gepflegt und gewartet wird. Klar kann man sich das auch manuell wieder einpflegen aber aufwendiger. Wenn in dem Datenbankserver nur Daten von nextcloud liegen spricht meiner Meinung nach nichts dagegen alles zu dumpen.
Ebenso würde ich überprüfen ob bei mount -t cifs schon SMBv3 oder mindestens SMBv2 verwendet wird sofern das NAS dies schon unterstützt. Ist einfach effizienter als das uralte und nicht mehr unterstützte SMBv1. Wenn das NAS nix anderes kann tja dann bleibt dir wenig übrig^^
Beim rsync würde ich zusätzlich noch den Parameter --nomeric-ids verwenden, warum ich das empfehle steht z.B. hier: https://wiki.ubuntuusers.de/rsync/#Sicherung-von-lokalem-Rechner-auf-entfernten-Rechner

 

[R.Kante]

Ja, momentan ist NextcloudPi in Verwendung. Weil du bisher kein besonderes Interesse an Vorher-Nachher-Zukünftig-Geschichten gezeigt hast, habe ich dir meine Planung hinsichtlich dessen nicht geschildert. Dann eben jetzt ;-) Zum Zeitpunkt der Versuche mit den genannten docker exec Befehlen habe ich eine Migration der Nextcloud, weg von Nextcloudpi, hin zu einer per docker-compose.yml konfigurierten Containerstruktur verfolgt. Also für die Services Nextcloud, MariaDB, LetsEncrypt und Nginx je einen Container.

Im Nextcloud-Support Forum habe ich für die Migration einen Verweis auf diese Prozedur gefunden, welche eben die auf selbiger Seite beschriebene BackUp-Prozedur beinhaltet. Deshalb möchte ich als Vorbereitung für die Migration genau dieser folgen. Bisher ging ich davon aus, dass die DB, welche Teil des NextcloudPi Images zu sein scheint, die DB ist, welche ich dafür brauche.

Bezüglich der SMB Version: da muss ich wohl noch etwas weiter recherchieren. Auf die Schnelle habe ich beim ZyXEL Support nur die Information gefunden, dass das NSA325v2 nur SMBv1 kann. Das bringt mich aber auf meine Ausgangsfrage zurück, sind NFS oder FTP brauchbare(re) Alternativen?

 

[snaxilian]

Du willst mich absichtlich falsch verstehen, korrekt? Sorry für Trolls ist mir meine Zeit zu schade. Was niemanden interessiert: Dinge die einmal waren und nicht mehr so existieren. Wenn du schreibst: Ich nutze Nextcloud dann ist der Informationsgehalt für alle die hier lesen, dass du Nextcloud verwendest und zwar im 0815-Standard-Setup. Also ein Linux, mysql/mariadb, nginx/apache und fertig. Vielleicht gehörst du ja zu denen, die einen Auto-Vergleich brauchen:
Du rufst ja auch nicht in einer Werkstatt an und sagst: Bei meinem Auto klappert was und ne Leuchte blinkt. Ich hab nen Golf. Der Mechaniker macht also die Annahme, dass du einen Golf mit Verbrenner hast und nicht, dass du nen eGolf oder einen auf Autogas umgerüsteten Golf hast denn dafür ist anderes Werkzeug oder andere Fähigkeiten notwendig.

Bei egal welchem Setup von Nextcloud braucht es eine Datenbank mit mehreren Tabellen wo alle möglichen Infos und Daten drin stehen. Für den Betrieb einer oder mehreren Datenbanken braucht es einen Datenbankserver. Unter Linux sind die gängigen Vertreter mysql, mariadb oder postgresql. Solche Datenbankserver haben bzw. können wie auch ein Betriebssystem mehrere Benutzerkonten haben mit unterschiedlichen Berechtigungen. Wenn man nicht ne Kanne Lack gesoffen hat und auf best practices und grundlegende Sicherheit pfeift dann gibt es einen 'root' Account zur Verwaltung mit dem man weitere DB-Benutzer und Datenbanken und Tabellen anlegt und so z.B. einen DB-User für Nextcloud anlegt und diesem Berechtigungen auf die Inhalte der notwendigen DBs gibt aber in der Regel nur die Rechte die zwingend notwendig sind. Viele dieser Einrichtungsschritte nehmen die Skripte wie nextcloudpi etc ab und verstecken es. Jetzt musst du dich eben damit beschäftigen

Du willst jetzt Hilfe, da ist relevant was du jetzt nutzt. Nicht was du mal irgendwann verwendet hast und nichts was du denkst irgendwann mal zu verwenden.
Wenn du schon in einem anderen Forum Fragen zum Backup gestellt hast warum dann hier nochmal nachfragen?

Da du beim rsync sowieso ein bwlimit angibst dürfte es fast egal sein ob du SMB, NFS oder FTP nimmst. Alle Protokolle haben ihre Nach- und Vorteile. Wenn ich "smb vs nfs vs ftp" bei Google eingebe ist das hier der erste Treffer: https://forum.ubuntuusers.de/topic/entscheidungshilfe-smb-nfs-ftp-welches-ist-das/
Dort sollten vermutlich die meisten deiner Fragen zu den drei Protokollen erklärt werden.

 

[R.Kante]

Danke für deine Mühe. Deine Hinweise und Informationen nehme ich ernst, übertrage sie auf meine Situation und bewerte sie. Wenn dich mein Verhalten oder meine Art und Weise provoziert, dann sei es so, Absicht ist es nicht. Jedenfalls versuche ich seit deinem ersten Post die mir entgegen gebrachten, flappsigen und zum Teil äußerst arroganten Äußerungen zu ignorieren. Auch durch den Vorwurf des Trollens fällt das mittlerweile sehr schwer.

Ein wenig Klärungsbedarf sehe ich bei einigen Punkte die offensichtlich nicht angekommen sind:

• Die Anpassungen am Schema F sind mir klar, umgesetzt und getestet, wie schon erwähnt. Dein Hinweis auf den DB-User hat mich etwas stutzig gemacht. Vermutlich ist nicht klar geworden, dass sowohl nm als auch pw Platzhalter sind. Auf die Kürzungen wegen Übersichtlichkeit habe ich jedenfalls eindeutig hingewiesen.
• In keinem anderen Forum habe ich Fragen zum Thema BackUp gestellt. Der Verweis auf die Migration ist das Ergebnis einer einfachen Recherche. Deswegen schrieb ich davon ihn gefunden zu haben.

An dieser Stelle ist das Thema für mich vorerst auch geklärt. Schönes Wochenende noch!