DecaTec

Programmieren, Fotografie, Home-Server und einiges mehr

Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript

Nextcloud Logo

Mit dem Betreiben der eigenen Nextcloud gehen natürlich auch einige administrativen Pflichten einher. So sollte sowohl das Betriebssystem, als auch die Cloud-Software auf dem aktuellsten Stand gehalten werden.

Ein weiterer wichtiger Punkt, den man nicht außer Acht lassen sollte, sind Backups der eigenen Cloud. Leider gibt es hier kein fertiges Skript oder Plugin, welches alles automatisch erledigt – hier ist also etwas Handarbeit gefragt.

Der folgende Artikel zeigt Schritt für Schritt, wie sowohl Backups angefertigt, als auch wieder zurückgespielt werden können. Die Nextcloud-Dokumentation liefert bereits eine recht detaillierte Anleitung für das Anfertigen von Backups, als auch für die Wiederherstellung. Dennoch lässt sich das Vorgehen hier und da noch etwas optimieren und v.a. auch (per Skript) automatisieren.

Ausgangspunkt ist wie immer die im Tutorial Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban gezeigte Konfiguration.

Update-Historie
  • 23.09.2017:
    • Hinweis auf Anpassung der Verzeichnis-Berechtigungen entfernt. Dies wird seitens der Nextcloud-Dokumentation nicht mehr empfohlen (siehe hier).
  • 26.03.2018:
    • Hinweis für Debian, wenn sudo -u www-data nicht klappt.

Grundsätzliches Vorgehen

Eine komplette Nextcloud-Instanz besteht immer aus drei Teilen:

  • Das Web-Verzeichnis von Nextcloud (z.B. /var/www/nextcloud)
  • Das Daten-Verzeichnis (z.B. /var/nextcloud_data)
  • Die Nextcloud-Datenbank

Wenn Backups der eigenen Cloud angefertigt werden sollen, dann sind immer diese drei Teile zu berücksichtigen.

Mit welchen Mitteln das Backup angefertigt wird, ist dabei zunächst einmal egal. Im Rahmen des Artikels werden aber nur Programme verwendet, die auf einer normalen Installation eines Ubuntu Servers verfügbar sind.

Man sollte sich im Vorfeld nur Gedanken über den Speicherort des Backups machen. Hier macht es wenig Sinn, das Backup auf der gleichen Festplatte zu speichern, auf der auch Nextcloud installiert ist. Im Falle eines Festplatten-Ausfalls ist sowohl die Nextcloud-Instanz, als auch das Backup verloren.

Besser ist hier die Verwendung einer externen Festplatte oder eines Netzlaufwerks (z.B. auf einem NAS). Im Rahmen des Artikels gehe ich davon aus, dass das Verzeichnis der Backups /mnt/Share/NextcloudBackup lautet.

Hinweis für Debian: Wenn bei Befehlen die unter einem anderen User ausgeführt werden sollen (Webserver-User, www-data), könnte unter Debian das Problem auftauchen, dass dies mit sudo -u www-data <Befehl> nicht funktioniert. Hier erscheint dann eine Meldung wie „www-data ist unavailable“. In diesem Fall wurde bei der Installation von Debian ein Passwort für den Benutzer root vergeben und in Folge dessen das Programm sudo gar nicht installiert. Wenn man daher sudo nicht verwenden kann oder will, dann kann man einen Befehl aber auch auf andere Weise unter einem anderen User ausführen. In diesem Fall verwendet man anstatt sudo -u www-data <Befehl> einfach folgendes: su -s /bin/sh www-data -c „<Befehl>“

Backup erstellen

Um ein Backup zu erstellen, sollte die Nextcloud-Instanz zunächst in dem Maintenance-Mode versetzt werden. Das sorgt dafür, dass kein Benutzer aktiv auf der Cloud arbeiten kann.

Als nächstes müssen das Hauptverzeichnis von Nextcloud gesichert werden. Dies ist im Normalfall unter /var/www/nextcloud zu finden (bitte den Punkt am Ende der Zeile beachten):

Neben dem Nextcloud-Verzeichnis muss auch das Datenverzeichnis von Nextcloud mit in das Backup einfließen. Dieses sollte idealerweise außerhalb des Web-Verzeichnisses liegen (z.B. unter /var/nextcloud_data). Auch hist wieder ein Punkt am Ende des Befehls:

Nun muss nur noch die Datenbank der Nextcloud-Installation gesichert werden. Dies geschieht mit folgendem Befehl:

Nun ist das Backup komplett, so dass Benutzer wieder mit der Cloud arbeiten können. Daher wird der Maintenance-Modus wieder beendet:

Backup zurückspielen

Ein Backup anzufertigen ist natürlich nur eine Seite der Medaille. Im Falle des Falles muss das Backup auch zurückgespielt werden können.

Vor der Wiederherstellung versetzen wir Nextcloud wie gewohnt in den Maintenance-Mode:

Da wir hier ein komplettes Backup wieder einspielen, sollte der Webserver zunächst ein mal gestoppt werden:

Vor der Wiederherstellung der Dateien der Cloud werden als erstes die entsprechenden Verzeichnisse gelöscht und neu angelegt. Dies sorgt dafür, dass keine Dateien aus dem Zustand vor dem Backup übrigleiben:

Nun gilt es zunächst das Nextcloud-Verzeichnis aus dem Backup wiederherzustellen. Da das Datum als Zeitstempel für das Backup diente, muss bei den folgenden Befehlen immer das korrekte Datum verwendet werden:

Das gleiche wird mit dem Datenverzeichnis von Nextcloud durchgeführt:

Anschließend werden die Verzeichnis-Berechtigungen noch einmal explizit gesetzt:

Zum Schluss wird noch die Datenbank wiederhergestellt. Dazu wird zunächst die Datenbank entfernt und neu angelegt (für die Ausführung der Befehle muss das Passwort des Nextcloud-Datenbankusers angegeben werden):

Das Einspielen des Backups geschieht durch folgenden Befehl:

Nun wird der Webserver wieder gestartet:

Zum Schluss muss noch ein Befehl abgesetzt werden, damit Nextcloud-Clients mitbekommen können, dass sich hier etwas durch das Wiederherstellen eines Backups verändert hat:

Zum Schluss wird Nextcloud wieder aus dem Maintenance-Mode geholt.

Nach diesen Schritten wurde ein Backup von Nextcloud wiederhergestellt und es kann wieder mit der Cloud gearbeitet werden.

Backup/Restore mit Bash-Skript

Ein Backup kann mit diesen Schritten jederzeit manuell ausgeführt oder wiederhergestellt werden. Mehr Komfort erhält man jedoch, wenn man die auszuführenden Befehle in einem Skript zusammenfasst.

Auf diese Weise können Backups mit nur einem Befehl automatisiert angefertigt oder wiederhergestellt werden.

Zu diesem Zweck habe ich ein GitHub Repository erstellt, welches die notwendigen Bash-Skripte enthält: 

Nextcloud-Backup-Restore @ GitHub

Hinweis: Ich habe die Skript-Dateien als Open Source auf GitHub zur Verfügung gestellt. Damit sind diese frei verfügbar und können auch von jedermann angepasst und verbessert werden. Ich übernehme allerdings keinerlei Haftung für den Einsatz dieser Skripte. Diese sollen lediglich als Basis für die Erstellung eigener Backup-Skripte für eure Nextcloud-Instanz dienen.

Zunächst werden die Skript-Dateien heruntergeladen. Durch die Anmeldung als root-Benutzer werden die Skripte im Home-Verzeichnis von root gespeichert. Dies macht Sinn, da für die Ausführung der Skripts root-Rechte benötigt werden:

Mit folgenden Befehlen werden die Dateirechte angepasst, so dass nur der Benutzer root Zugriff auf diese Dateien hat und diese auch ausführen kann:

Wichtig: Die Skripte sind nicht direkt ausführbar, sondern erfordern noch Anpassungen an die konkrete Server-Umgebung (Pfade, Benutzernamen, etc.)! Hinweise dazu sind auch in den Skript-Dateien hinterlegt.

Bitte führt diese Skripte nicht „blind“ auf eurem System aus, sondern versucht, die ausgeführten Befehle zu verstehen und entsprechend eurer Nextcloud-Installation anzupassen.

Wenn die Skripte angepasst wurden, können diese direkt ausgeführt werden:

Das Backup wird automatisch im entsprechenden Verzeichnis, welches im Backup-Skript angegeben wurde, gespeichert (z.B. /mnt/Share/NextcloudBackups/20170912_073953).

Wiederhergestellt werden kann ein Backup durch das Restore-Skript. Dieses erwartet den Zeitstempel eines vorhandenen Backups als Parameter:

Die Skripts sind so konzipiert, dass diese keine Benutzereingaben erfordern. Dadurch kann die Ausführung von Backups auch einfach automatisiert werden. Per Cronjob ist es beispielsweise denkbar, dass täglich nachts um 03:00 automatisch ein Backup der Nextcloud-Instanz auf einem NAS gespeichert wird.

Fazit

Auf den ersten Blick ist das Anfertigen von Backups und ggf. die Wiederherstellung nicht weiter kompliziert. Trotzdem ist es wichtig, alle auszuführenden Schritte zu verstehen und genau zu befolgen.

Am Ende noch der wichtigste Tipp: Nichts ist ärgerlicher, als regelmäßig angefertigte Backups, die aber im Ernstfall nicht wiederhergestellt werden können! Daher sollte das ganze Vorgehen (Backups anfertigen und auch wieder zurückspielen) mindestens einmal durchgespielt werden – und das Ganze am besten, bevor eure private Cloud in den produktiven Betrieb übergeht.

Der Aufwand lohnt sicher aber: Wenn ihr sichergehen könnt, dass euer Vorgehen zum Erstellen und Wiederherstellen von Nextcloud-Backups im Ernstfall funktioniert, könnt ihr auch ruhigen Gewissens weitere Benutzer auf eure Cloud loslassen.

Weiterführende Artikel

Links

, , , , ,

Kommentare: 43

  • Bernd sagt:

    Hallo Jan,

    wie immer einfach Klasse was du dir für Mühe machst!
    Vielen lieben Dank dafür.

    Wie hast du das Beispiel Verzeichnis /mnt/Share/NextcloudBackup eingebunden mit SMB?

    Vielen Dank

    Gruß Bernd

    • Jan sagt:

      Hi Bernd,

      in meinem Fall ist es eine Freigabe im Netzwerk. Eingebunden wird dies dann mittels cifs-utils und einem Eintrag in der /etc/fstab, damit das Laufwerk beim Systemstart gemounted wird. Eine sehr gute Erklärung zu diesem Thema findest du hier.

      Gruß,
      Jan

  • Hans sagt:

    Hallo Jan,

    Ich erhalte auf allen System nach dem Ausführen des Backups diese Meldung.
    Nextcloud is in maintenance mode – no app have been loaded

    In der config.php der Nextcloud ist der Eintrag für die Maintenance-Eintrag vorhanden.

    Das Backup wird jedoch erfolgreich angelegt.

    Gruß Hans

    • Jan sagt:

      Hi Hans,

      ah, da hatte sich noch ein Fehler bei den Befehlen eingeschlichen, mit dem der Maintenance-Mode gesteuert wird (falsche Pfadangabe bei cd). Diese müssen natürlich wie folgt lauten:
      cd /var/www/nextcloud
      sudo -u www-data php occ maintenance:mode --off

      Habe den Artikel angepasst. Danke für den Hinweis!

      Gruß,
      Jan

      • Hans sagt:

        Hallo Jan,

        im Backupskript (NextcloudBackup.sh) ist scheinbar auch noch ein Fehler, obwohl die Pfadangaben passen, wird die gleich Meldung ausgegeben (Nextcloud is in maintenance mode – no app have been loaded).

        Beim deaktivieren des Maintenance-Mode.

        Ich gehe jedoch davon aus das sich diese Meldung nicht vermeiden lässt.

        Gruß Hans

        • Jan sagt:

          Hi Hans,

          ja, die Meldung ist mir auch aufgefallen. Ich gehe davon aus, dass dies passiert, wenn der Webserver (und auch Nextcloud) wieder gestartet wird und zu diesem Zeitpunkt der Maintenance-Mode noch aktiv ist.

          Bei meinen Tests war der Maintenance-Mode allerdings nach der Ausfürung des Befehls deaktiviert und ein normales Anmelden war möglich.
          Wird der Maintenance-Mode bei dir nicht deaktiviert?

          Gruß,
          Jan

          • Hans sagt:

            Hallo Jan,

            ja, deaktiviert und danach wieder aktiviert.

            Gruß Hans

          • Jan sagt:

            Hi Hans,

            komme nicht ganz hinterher:
            Wenn du das Backup-Skript ausgeführt hast, kannst du dich dann mit einem normalen User (nicht mit dem Admin) an der Cloud anmelden? Wenn ja, dann ist der Maintenance-Mode deaktiviert und alles ist gut. In diesem Fall kannst du die Meldung einfach ignorieren.

            Gruß,
            Jan

  • Hans sagt:

    Hallo Jan, Backup funktioniert, Anmeldung funktionieren nach dem Backup auch. Es ging mir nur um die Meldung. Nachdem ich hier über die Meldung bichts gelesen habe, wollte ich mal nachfragen.

    Vielen Dank

    Gruß Hans

  • Bernd sagt:

    Hallo Jan,

    ich habe das Script erfolgreich getestet, es gibt keine Fehlermeldungen oder ähnliches und läuft perfekt durch, es dauert allerdings (über 100GB :) )
    Das einzige das nicht funktioniert hat, war das Klonen von Github, hier hat er zwar Scripte angelegt, aber iwie habe ich darin das eigentliche Script nicht gefunden.
    Ich habe die Scripte dann mit Copy und Paste erstelle und angepasst (funst top)
    Danke für die Arbeit und Mühe

    Gruß Bernd

    • Jan sagt:

      Hi Bernd,

      super, danke für die Rückmeldung!
      Du hast Recht: Die Download-Links von GitHub waren falsch, habe sie aber angepasst. Nun sollte das Herunterladen per wget klappen.

      Gruß,
      Jan

  • Antonio Catany sagt:

    Servus Jan,
    deine Serie über Nextcloud ist echt toll! Ich lerne eine Menge damit und bin ich sehr dankbar dafür.
    Meine Versuche aber deine Backup-Scripten um Anzahlbegrenzung zu ergänzen scheitern kläglich. Vielleicht eine Idee? Hier ein Auszug von ein Script aus Nextcloudpi (https://github.com/nextcloud/nextcloudpi) :

    # delete older backups
    [[ $BACKUPLIMIT_ != 0 ]] && {
    local NUMBKPS=$( ls „$DESTDIR_“/nextcloud-bkp_* | wc -l )
    [[ $NUMBKPS > $BACKUPLIMIT_ ]] && \
    ls -t $DESTDIR_/nextcloud-bkp_* | tail -$(( NUMBKPS – BACKUPLIMIT_ )) | while read -r f; do
    echo -e „clean up old backup $f“
    rm „$f“
    done
    }

    lg aus Wien

  • Phil sagt:

    Hallo Jan,

    ein super Artikel und für alle die Nextcloud einsetzen eine sinnvolle Ergänzung. Danke für deine Mühe.
    Aufgefallen ist mir, dass es vllt sinnvoll wäre noch eine Sache zu erwähnen, um es ganz abzurunden!
    Beim Restore der Datenbank in ein neues Major-Release wird zwingend der Befehl vorausgesetzt, bevor der Maintenance Mode wieder ausgeschaltet werden kann:
    sudo -u www-data php occ upgrade

    Des weiteren ist noch ein Schreibfehler beim GitHub Download:
    wget hhttps://

    Alles in allem, danke für deine Mühe!

    Liebe Grüße
    Phil

    • Jan sagt:

      Hi Phil,

      den Download-Link via wget habe ich angepasst, vielen Dank für den Hinweis!

      Allerdings verstehe ich den Punkt „Restore der Datenbank in ein neues Major-Release“ nicht so ganz: Das Tutorial basiert darauf, dass Filedir (/var/www/nextcloud), Datadir (/var/nextcloud_data) und NC-DB immer eine Einheit bilden. Daher ist ein Backup immer ein kompletter „Snapshot“ der Nextcloud, der im Falle eines Restore auch komplett wiederhergestellt wird.
      Nur die Datenbank und/oder das Filedir wiederherzustellen würde ich nun nicht empfehlen. Daher wäre ein Hinweis auf das php occ upgrade evtl. etwas verwirrend.

      Gruß,
      Jan

  • Marc sagt:

    Hallo Jan,
    super Artikel, gibt es eigentlich auch eine Möglichkeit einzelne Datei aus einenm so erstellten Backup bei aktivierter Encryption zurückzusichern?

    Würde mich sehr über ein Antwort freuen

    Gruß marc

    • Jan sagt:

      Hi Marc,

      nein, ich denke nicht, dass du einzelne Dateien aus einem Backup wiederherstellen kannst. Die Verschlüsselung wird durch die Cloud sicher gestellt, d.h. alle Dateien, die entschlüsselt werden sollen, müssen die Cloud „passieren“. Zumindest ist mir da keine andere Möglichkeit bekannt.

      Gruß,
      Jan

  • Michael sagt:

    Hallo Jan,

    ich bin’s noch einmal :)

    Ich würde gerne das Skript nutzen, aber unter Debian Stretch geht sudo -u nicht. www-data ist unavailable, aus Sicherheitsgründen wohl zurecht. Hast Du ne andere Idee?

    Herzliche Grüße
    Michael

    • Jan sagt:

      Hi Michael,

      damit hatte ich sowohl unter Ubuntu, als auch unter Debian (Raspbian) keine Probleme.
      Wie lautet der konkrete Befehl, den du hier versuchst auszuführen?

      Gruß,
      Jan

      • Michael sagt:

        Moin Jan,

        vielen herzlichen Dank für Deine Nachricht.

        Ich habe den Befehl in Deiner Anleitung benutzt: sudo -u www-data usw. Debian nutzt ja kein sudo, wenn man beim Installieren ein root-Passwort vergibt. Dass das nicht gehen wird, wusste ich also schon vorher.

        su www-data geht auch nicht, weil www-data sich ohne Passwort nicht einloggen kann. Aus Sicherheitsgründen sollte imo www-data auch kein Passwort bekommen. Der Server ist ja aus dem Netz erreichbar.

        Gibt es da noch einen anderen Weg?

        Herzliche Grüße
        Michael

        • Jan sagt:

          Hi Michael,

          schau mal hier, das sollte eigentlich helfen. Wundert mich ehrlich gesagt, dass das unter Debian nicht „einfach so“ funktioniert.

          Gruß,
          Jan

          • Michael sagt:

            Hallo Jan,

            vielen herzlichen Dank für Deine Nachricht.

            sudo nachzuinstallieren und Debian dadurch „unsicherer“ zu machen, möchte ich nicht.

            Aber su -s /bin/sh www-data funktioniert gut. Damit lässt sich der Wartungsmodus ohne Probleme ein- und ausschalten. Und die Sicherheit des Systems bleibt erhalten.

            Danke Dir!

            Herzliche Grüße
            Michael

          • Jan sagt:

            Hi Michael,

            danke für den Tipp!
            Ich habe gleich mal einen Hinweis im Artikel hinzugefügt, wenn das normale sudo -u www-data … unter Debian nicht funktionieren sollte.

            Gruß,
            Jan

  • Michael sagt:

    Hallo Jan,

    ich bin es noch einmal. Ich versuche gerade Dein Backupskript anzupassen. sudo -u www-data geht ja bei mir nicht. Das heißt ich muss in die neue Shell öffnen (via su -s /bin/sh www-data), dann den Befehl ausführen php occ maintenance:mode –on or –off und dann wieder raus aus der Shell. Hast Du vielleicht ne Idee, wie man das elegant programmieren kann, so dass es via Skript läuft. Mir fällt irgendwie nichts ein. Ich komme zwar in die Shell, aber der Befehl wird nicht ausgeführt, auch mit einem kleinen timeout nicht.

    Danke!

    Herzliche Grüße
    Michael

  • Michael sagt:

    Für das Skript würde unter Debian folgendes benutzen:

    su -s /bin/bash „${webserverUser}“ -c „php occ maintenance:mode –on“ oder eben su -s /bin/bash „${webserverUser}“ -c „php occ maintenance:mode –off“

    • Jan sagt:

      Hi Michael,

      ok, danke für den Hinweis. Ich denke, ich werde mir die Tage mal eine Debian-Installation aufsetzen und das ganze nochmal näher ansehen.
      Um das Skript unter Debian lauffähig zu machen, musst du wohl sämtliche Befehle anpassen, die mit sudo -s… beginnen. Du kannst dir das GitHub-Repository ja auch clonen und hier deine Anpassungen einbringen. Im Original-Repository würde ich dann einen Link auf dein Repository einfügen.

      Gruß,
      Jan

      • Jan sagt:

        Hi Michael,

        so, ich habe mal etwas recherchiert und rumprobiert. Hier ein kleines Update:
        Der entscheidende Unterschied zwischen Debian und Ubuntu ist hier, dass er bei Debian bei der Installation zunächst nach einem Passwort für den Benutzer „root“ fragt. Erst danach wird der „normale“ Benutzer (mit erneuter Passwortabfrage) angelegt. Nur den zweiten Schritt kennt man von Ubuntu.
        Wenn man nun für den Benutzer root ein Passwort vergibt, dann wird sudo gar nicht erst installiert. Das ist dann wohl die normale Vorgehensweise bei Debian: Wenn man was mit Root-Rechten machen will, dann muss man sich auch mit dem root-Benutzer anmelden.
        Wenn man für den root-Benutzer kein Passwort vergibt (bei der Installation), dann wird sudo installiert und der erste Benutzer zu den „sudoers“ hinzugefügt. Folglich ist das Verhalten dann zu Ubuntu identisch.

        Bevor du nun deinen Rechner neu installierst: Man dann das Ubuntu-Verhalten auch unter Debian nachrüsten (wenn ein PW für root vergeben wurde):
        Einfach als Benutzer root anmelden und dann
        su root
        apt install sudo
        usermod -aG sudo <benutzer>

        Danach die Kiste mal neu starten und dann kannst du auch mit deinem normalen Benutzer mit sudo -s arbeiten und das Ausführen unter einem anderen Benutzer sollte dann auch problemlos funktionieren.

        PS: Habe das auch im Artikel nochmals etwas besser beschrieben.

        Gruß,
        Jan

  • Michael sagt:

    Hallo Jan,

    vielen herzlichen Dank für Deine Nachricht und Mühen.

    Das mit sudo und root wusste ich. Aus Gründen der Sicherheit halte ich es dennoch für sinnvoll www-data keine sudo-Rechte zu geben. Mit su -s /bin/bash www-data -c “Befehl“ komme ich gut hin. Und das Skript läuft ohne Probleme durch. Ich habe einen Cronjob angelegt, der das Skript wöchentlich um 4 Uhr ausführt. Die Ausgabe geht /dev/null 2>&1.

    Herzliche Grüße
    Michael

    • Jan sagt:

      Hallo Michael,

      Moment, da habe ich mich wohl falsch ausgedrückt: Du fügst in diesem Fall nicht den Benutzer „www-data“ zu den Sudoers hinzu (hier wüsstest du ja gar kein Passwort), sondern deinen normalen Benutzer, mit dem du sonst immer arbeitest. Dieser darf dann etwas mit Root-Rechten ausführen. Dann ist es „Ubuntu-like“.
      Ansonsten dürfte es ausreichen sudo mit apt-get install sudo nachzuinstallieren. Damit solltest du dann das erreichen, was du eigentlich willst: Eingeloggt als root kannst du so einen Befehl unter einem anderen User ausführen (ohne dass dieser Benutzer zu den Sudoers gehört und damit keine Root-Rechte hat).

      Gruß,
      Jan

  • Tino Soldan sagt:

    Hallo Jan,

    ich bin auf der Kommandozeile nicht fit. Kannst Du mir bitte die Befehle für den Cronjob der Sicherung täglich um 3 Uhr und sonntags um 3 Uhr liefern. Ich muss mir dann noch überlegen, welchen ich anwenden werde…
    Dankeschön schon mal!

    • Jan sagt:

      Hi Tino,

      OK, ganz von vorn:
      sudo -s
      cd ~
      mkdir ~/scripts

      Hier erstellst du einen Ordner für Skripte im Home-Verzeichnis von Root. Nun das Backup-Skript von hier dort reinkopieren. Das Skript an sich ist nur ein Blueprint, es muss noch an deine Umgebung angepasst werden (Passwörter, etc.).
      Anschließend wird das Skript ausführbar gemacht:
      chmod +x ~/scripts/NextcloudBackup.sh
      Am besten das Skript mal so ausführen und schauen, ob alles korrekt durchläuft. Es ist sicher auch nicht verkehrt, den Restore (mit dem zweiten Skript) mal auszuprobieren, um zu sehen, ob auch das klappt.
      Wenn das Backup-Skript irdentlich durchläuft, dann kann ein Cronjon angelegt werden:
      crontab -e
      Täglich 03:00:
      0 3 * * * ~/scripts/NextcloudBackup.sh
      Jeden Sonntag 03:00:
      0 3 * * 0 ~/scripts/NextcloudBackup.sh

      Gruß,
      Jan

      • Tino Soldan sagt:

        Vielen Dank für Deine Antwort. Die Anpassung der Scripte hatte ich bereits vorgenommen und auch ein Backup sowie das Restore getestet. Hatte alles prima funktioniert und mir deshalb gestern eine SSD geordert, auf der die Backups dann zukünftig landen sollen. Danke auch für den Tipp mit dem Verzeichnis im Home von root, hätte ich sonst so nicht gemacht…

  • Wolfgang sagt:

    Hallo Jan,

    ich komme nicht weiter. Ich habe alles wie bei Tino beschrieben eingestellt. Bei mir wird der Job nicht ausgeführt. Wenn ich crontab -e als root eingeben wird auch immer wieder ein tmp-Pfad angegeben. Wo muss dann diese Cron-Datei liegen?
    Der Inhalt ist:
    00 03 * * 0 letsencrypt renew >> /var/log/letsencrypt-renew.log && /etc/init.d/nginx reload > /dev/null 2>&1
    45 10 * * * ~/scripts/nextcloudbackup.sh
    Ich befürchte auch die Zertifikate werden nicht erneuert. Unter /etc/crontab ist der Inhalt:
    # m h dom mon dow user command
    17 * * * * root cd / && run-parts –report /etc/cron.hourly
    25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts –report /etc/cron.daily )
    47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts –report /etc/cron.weekly )
    52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts –report /etc/cron.monthly )
    #
    Was mache ich falsch?

    • Jan sagt:

      Hi Wolfgang,

      bist du auf Debian/Ubuntu unterwegs? Dann brauchst du für die Zertifikats-Erneuerung keinen eigenen Cronjob einrichten, der wird nämlich automatisch angelegt.
      Funktioniert der Backup-Job? Falls nicht, probiere es mal mit /home/root als Pfadangabe.
      Dass beim Anlegen des Cronjobs ein temp-Pfad angezeigt wird ist normal.

      Gruß,
      Jan

  • Philipp sagt:

    Hallo Jan,
    ich habe dein Script auf meine Bedürfnisse angepasst, aber immer wenn ich es ausführen will bleibt er beim Teil mit dem DB Backup stehen und will von mir das DB Passwort haben. Gebe ich es ein macht er weiter. Ich habe es jetzt mehrfach geprüft, ich habe das korrekte Passwort im Script hinterlegt. Woran kann das liegen ?

    Danke,
    Gruss Philipp

    • Jan sagt:

      Hi Philipp,

      hm, eigentlich kann man hier nicht viel falsch machen. Wenn du nur die Variable mit dem Passwort geändert hast, dann sollte es eigentlich gehen.
      Wenn du direkt den „Code“ angepasst hast, dann musst du darauf achten, dass zwischen dem -p und dem Passwort selbst kein Leerzeichen mehr kommt.

      Gruß,
      Jan

  • Thomas sagt:

    Hallo Jan,
    zunächst einmal herzlichen Dank für den ausführlichen Artikel!
    Ich nutze Linux zwar schon seit Jahren, bin aber eigentlich nur Anwender und nicht so tief im Thema drin.
    Deswegen versuche ich gerade einige Dinge nachzuvollziehen.
    Hier zu eine Frage: Du weist explizit auf den Punkt am Ende der tar Befehlszeilen hin. Welchem Zweck dient dieser?

    VG
    Thomas

    • Jan sagt:

      Hi Thomas,

      führe den Befehl mal ohne den Punkt am Ende aus, dann wirst du eine etwas spaßig formulierte Fehlermeldung von tar bekommen:

      tar: Cowardly refusing to create an empty archive

      Er weiß dann nämlich nicht, was er in das Archiv packen soll. Der Punkt sagt hier nämlich einfach aus, dass er alle Inhalte des Verzeichnisses packen soll, welches mit dem Parameter -C angegeben wurde.

      Gruß,
      Jan

  • Thomas sagt:

    Hallo Jan,
    wirklich eine etwas ungewöhnliche Fehlermeldung :-)

    Danke für die Info
    Thomas

  • Hendrik sagt:

    Hallo Jan,

    super Anleitung und auch die Skripte laufen wunderbar. Ich habe eine Frage und zwar ob folgendes Szenario möglich/ sinnvoll und wie es korrekt umzusetzen ist.

    Ausgangspunkt: Das Skript ist am Ende und das Backup liegt im entsprechenden Ablageort.

    Jetzt soll das Skript erweitert werden:
    1. Ordner verschlüsseln
    2. Per WebDav eines Clouddienstleisters ein Laufwerk mounten (wo würde man zB die Logindaten am sinnvollsten hinterlegen)
    3. Verschlüsseltes Backup in das gemountete Laufwerk kopieren und dort auch auf eine maximal Anzahl von Backupdateien prüfen und ggf. löschen.

    Viele Grüße
    Hendrik

    • Jan sagt:

      Hi Hendrik,

      das sind recht spezielle Anforderungen. Daher ist es unwahrscheinlich, dass ich dies direkt in die Skripte im GitHub-Repo übernehmen werde.
      Hier nur ein paar Hinweise:

      • WebDAV kannst du über davfs2 mounten, wie hier beschrieben.
      • Dann kommt es natürlich drauf an, wie du die Daten verschlüsseln willst. Ich nutze für solche „Public-Cloud-Uploads“ gern Cryptomator. Es gibt für Cryptomator auch eine CLI-Version, allerdings ist diese noch im Beta-Stadium.
      • Wenn diese beiden Punkte erst mal klar sind, dann ist der Rest auch kein Problem mehr, da die Verschlüsselungs-Software den Speicher transparent in das System einbinden sollte. Hier gibst du dann einfach das entsprechende Laufwerk (oder besser gesagt: den gemounteten Ordner) als Ziel des Backups an.

      Sorry, dass ich hier nur Ansätze liefern kann, aber es hängt eben viel von der entsprechenden Software für die Verschlüsselung ab.

      Gruß,
      Jan

      • Hendrik sagt:

        Danke für die Antwort! Das mounten und speichern auf dem externen Cloudanbieter klappt gut. Das CLI für Cryptomator klingt interessant scheint aber derzeit nicht der Hauptfokus zu sein, da der letzte Commit schon 10 Monate alt ist. Ich schaue es mir mal an.

        Gruße
        Hendrik

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.