Frage zur Backup-Strategie

    Ich hab hier und anderswo gesucht, aber entgegen meiner Erwartung leider keine Antworten auf meine Frage gefunden. Aber ich kann mich dusselig beim Suchen angestellt haben,


    Auf meinem vServer hier (Karneval 2020) läuft eine Nextcloud, die als Test-Spielerei angelegt wurde, aber nun doch anwächst, es wird also ein Backup nötig.

    Ich nutze neben dem vServer hier noch ein Webhosting (EiWoMiSau) und zu Hause steht lokal ein NAS.

    Da das Webhosting noch reichlich Speicher frei hat, dachte ich darüber nach, das als Backup-Ziel zu definieren. Dabei wollte ich das Webhosting in /mnt/backup_xy/ mounten. Eigentlich per SSH, aber das Webhosting hat nur einen SSH-User, der Zugriff auf alles hat, also auch auf die anderen Instanzen. FTP-User lassen sich im Webhosting wesentlich besser auf nur den einen relevanten Order beschränken. Wäre in dem Fall mounten via FTPS sicherer? Oder zerdenke ich das ganze zu sehr? Da ich meinen vServer bei Einrichtung schon halbwegs gut abgesichert habe (ohne diese hier im Forum gefundene Anleitung, aber trotzdem quasi alles (außer Monitoring)), brauch ich mir auch nicht zu sehr Gedanken um den SSH-Zugang machen, der "Zugriff auf alles" hat?

    Als Alternative hätte ich noch mein NAS im Angebot, was ich aber lokal und ohne Portforwarding im Router betreiben möchte. Ggf. könnte ich damit Backups pullen?

    Ich blicke bei dem Vorhaben nicht so ganz durch, ob dein Backup ein Snapshot des Servers oder ein Datenback des Nextcloud sein soll. Ich mache es aber kurz: Snapshot des Servers kann man via Control Panel bei Netcup anlegen, für ein Datenbackup von Nextcloud empfehle ich "Cloud Sync", vorausgesetzt ein Synology NAS wird eingesetzt. Alternativ existiert noch "rsync" um 2 Linux Systeme zu synchronisieren.

    VPS und Webhosting ist eine ganz ganz schlechte Idee. Warum? Darum.


    Du kannst dein NAS mit deinem VPS per Wireguard verbinden und dann durch das VPN direkt mit diesem "reden". Braucht keine Portforwardings, static IPs oder solches Zeugs.

    Pullen halt ich afaik für eine schlechte Idee, weil du ja wenn den ganzen Server sichern möchtest. Und dann braucht das NAS einen Root-Zugang zum Server. Und dann... neeee, lass mal. Bin da nicht so für. Wir sind nicht so.


    Bastel dir da lieber eine VPN Kopplung mit Wireguard und spiel deine Backups per Borg vom VPS auf das NAS. Borg kannst du auch so einrichten, dass dein VPS nur auf dem NAS hinzufügen und nicht löschen kann. Das Pruning der Backups macht das NAS dann selbst.


    EDIT:
    Achso - die Datenbank natürlich vorher mit mysqldump dumpen, sonst hast du keine konsistenten Daten.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    Zitat von whoami0501

    Pullen halt ich afaik für eine schlechte Idee, weil du ja wenn den ganzen Server sichern möchtest. Und dann braucht das NAS einen Root-Zugang zum Server. Und dann... neeee, lass mal. Bin da nicht so für. Wir sind nicht so.

    Prinzipbedingt sind Pull Backups sicherer als Push. Die Wahrscheinlichkeit, dass jemand in das NAS im internen Netzwerk eindringt ist sehr viel geringer als ein Eindringling im öffentlich erreichbaren VPS.


    Borg & Co (also Push) kann man natürlich so einrichten, dass der VPS auf dem NAS nur zusätzliche Backups anlegen kann und ein Eindringling die vorhandenen Backups nicht löschen kann. Aber auf jeden Fall hat der Eindringling so schon mal einen Zugang ins interne Netz, den es bei Pull einfach nicht gibt.

    Ich habe ja eine Abneigung gegenüber Foristen, die eine Frage stellen und dann ohne Rückmeldung vollständig im Nirvana verschwinden. Leider musste ich kurz weg, aber jetzt habe ich zwischen den Jahren wieder mehr Zeit hierfür.


    Danke für eure Antworten. Ich habe mich erschrocken, habe geschmunzelt und habe gelernt (hoffentlich).

    Ich lass das Webhosting jetzt aus der Rechnung draußen und pulle vom NAS per rsync die Ordner und den mysqldump (den ich automatisiere, wenn alles klappt). Während ich das hier schreibe, lösche ich alles und spiel den ganzen Spaß einmal zurück.


    Ein paar Dinge sind mir trotzdem unklar:

    * Ist es sehr dumm, den mysqldump in /var zu legen, um ihn von dort zu pullen? Sollte ich den woanders ablegen? Dazu habe ich keine Informationen gefunden.

    * Ich las, man solle den backup-user als sudoer pullen lassen, was ich jetzt nicht gemacht habe, weil ich es für falsch halte, dem backup-user sudo-Rechte zu geben. Das oben erwähnte Backup hat problemlos geklappt, aber kann mir der Verzicht auf sudo trotzdem langfristig Probleme machen?

    Zitat von balthasar

    * Ich las, man solle den backup-user als sudoer pullen lassen, was ich jetzt nicht gemacht habe, weil ich es für falsch halte, dem backup-user sudo-Rechte zu geben. Das oben erwähnte Backup hat problemlos geklappt, aber kann mir der Verzicht auf sudo trotzdem langfristig Probleme machen?

    Wenn eine Datei root:root gehört und others keine Rechte darauf hat, kannst du da in Probleme laufen, weil dein Backupuser sie ohne sudo nicht lesen kann.



    Zitat von balthasar

    * Ist es sehr dumm, den mysqldump in /var zu legen, um ihn von dort zu pullen? Sollte ich den woanders ablegen? Dazu habe ich keine Informationen gefunden.

    Im Grunde ist das egal. Wichtig ist: am Zielort muss a) Platz sein und b) müssen die Rechte der Dumps so gesetzt sein, dass da kein anderer User reinschauen kann.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    Zitat von balthasar

    * Ist es sehr dumm, den mysqldump in /var zu legen, um ihn von dort zu pullen? Sollte ich den woanders ablegen? Dazu habe ich keine Informationen gefunden.

    Wenn die Ordnerrechte stimmen, sodass nur root und maximal der Backupuser (für den Download) Zugang haben: Nein, spricht nichts dagegen.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)