Skip to content

Restic - Ein Backupkonzept - Automatisieren!

Verschoben Restic
1 1 1.3k
  • Nach der Erstellung von folgendem Artikel Restic - Ein Backupkonzept habe ich eine Zeit lang gebraucht um mir ein vernünftiges Konzept zu erstellen. Backup's sind eine relativ komplexe und schwierige Materie. Wo lagert man? Was lagert man? Wie sichert man die Daten? usw.

    Wichtige Daten in der eigenen Wohnung zu sichern ist so lange eine gute Idee, bis die Wohnung mal brennt oder die Datenspeicher gestohlen werden. Auf dem Smartphone, das wäre auch noch eine Lösung. In der Cloud!? Hat was, aber ich traue allen kommerziellen Anbietern nicht über den Weg. Was machen? Man nimmt was eigenes, z.B. eine Nextcloud Installation. Da hat man weitestgehend alles in der eigenen Hand. Bleibt das Problem, das wir sehr wichtige Daten NUR verschlüsselt in der Cloud ablegen. Wir wollen es einem evt. Eindringling ja nicht zu einfach machen 😉

    Gut, das mit der Verschlüsselung haben wir ja gelöst, Restic speichert alle Backup's verschlüsselt. Bei der Suche nach einem Konzept bin ich in der Bedienungsanleitung über die Backends gestolpert, die Restic alle so unterstützt.

    0_1524762108060_restic_backends.png

    Die kommerziellen Sachen scheiden aus usw. Am Ende bin ich über Rclone gestolpert.

    Rclone is a command line program to sync files and directories to and from

    Rclone syncronisiert also einen Ordner mit einem Clouddienst. Und da kommt nun Restic ins Spiel, Restic nutzt Rclone zum Speichern der Daten in der Cloud. RClone unterstützt Nextcloud (natürlich auch Owncloud). Somit hätten wir ein gutes Team um Daten verschlüsselt in der Cloud abzulegen, welches sich auch relativ einfach automatisieren lassen sollte. Ok, fangen wir vorne an. Ich gehe von einer funktionierenden Restic Installation aus. Als Backend sollte eine Nextcloud Installation irgendwo im Netz laufen. Auf geht's...

    Rclone Installation

    Dieses Script installiert Rclone auf dem Rechner.

    curl https://rclone.org/install.sh | sudo bash
    

    Nach der erfolgreichen Installation kommt folgendes

    rclone v1.40 has successfully installed.
    Now run "rclone config" for setup. Check https://rclone.org/docs/ for more details.
    

    Rclone konfigurieren

    Mit

    rclone config
    

    stellt man die wichtigsten Parameter für Rclone ein.

    • Den Namen der Remoteverbindung - nextcloud
    • Den Type des Datenspeichers - 20 (Webdav)
    • URL of http Host - Den Webdav Pfad zu Eurer Nextcloud Installation
    • Name des Webdav Services - 1 (Nextcloud)
    • User Name - User Name (In Nextcloud festlegen!)
    • Passwort - Passwort (In Nextcloud festlegen)

    Das ganze bestätigen und kurz testen.

    rclone ls nextcloud:
    

    Nun sollte der Inhalt des Verzeichnisses ausgegeben werden.

    frank@frank-MS-7A34 ~ $ rclone ls nextcloud:
    5 TESTING.txt
    

    Erledigt, Rclone läuft. Nun der Teil mit Restic....

    Restic

    Nun schauen wir uns das mal mit Restic etwas genauer an.

    Beim ersten Test bekam ich immer eine Fehlermeldung

    frank@frank-MS-7A34 ~ $ restic -r rclone:nextcloud init
    Fatal: create repository at rclone:nextcloud failed: invalid backend
    If the repo is in a local directory, you need to add a 'local:' prefix
    

    Ok, kurz gegrübelt, das Backend ist drin auf github gecheckt. Klick, ich hatte eine alte Version installiert. Also schnell die neue Version gebaut und das Ganze sah schon besser aus.

    frank@frank-MS-7A34 ~/restic $ restic -r rclone:nextcloud:TEST init
    enter password for new repository:
    enter password again:
    created restic repository 7d6d14e068 at rclone:nextcloud:TEST
    

    Gut, läuft so weit. Kurz noch einen Anmerkung zum Pfad. Nehmen wir folgende Rclone Einstellung an.

    https://PFAD_zu_NEXTCLOUD/remote.php/webdav/BACKUP
    

    Der Restic Aufruf

    rclone:nextcloud:TEST
    

    zeigt auf einen Ordner innerhalb des Ordners Backup. Als Pfadangabe:

    https://PFAD_zu_NEXTCLOUD/remote.php/webdav/BACKUP/TEST
    

    Somit hätten wir jetzt das Repo vorbereitet und können jetzt unsere Daten dort speichern.

    frank@frank-MS-7A34 ~/restic $ restic -r rclone:nextcloud:TEST backup /home/frank/Bilder/21.04/
    enter password for repository:
    password is correct
    found 2 old cache directories in /home/frank/.cache/restic, pass --cleanup-cache to remove them
    

    Hier sieht man einen Aufruf um aus dem Ordner 21.04 die Bilder in Nextcloud zu sichern.Das Passwort wird abgefragt, und wenn korrekt wird gesichert. Im Beispiel tauchen noch alte Cache Dateien auf, hiermit bekommt man die weg.

    restic -r rclone:nextcloud:TEST backup /home/frank/Bilder/21.04/ --cleanup-cache
    

    Cronjob anlegen

    Schnell ein Script für den Cron schreiben. Das Script heißt backup.sh

    #!/bin/bash
    # Script um mit Restic & Rclone Daten automatisiert zu sichern!
    
    # PW hinterlegen
    export RESTIC_PASSWORD=12345678
    
    #Was soll gesichert werden?
    backup_pfad=/media/NAS/
    
    #Programm Start
    restic -r rclone:nextcloud:Daten backup $backup_pfad
    

    Einen Cronjob anlegen

    crontab -e
    

    Folgendes eingeben

    # m h  dom mon dow   command
    00 20 * * * /home/frank/backup.sh
    

    Speichern - Fertig! 😇

    Jeden Tag um 20:00 Uhr werden die Daten entsprechend gesichert!

  • Forgejo Installation mit Podman Quadlet auf Hetzner VM

    Podman forgejo podman quadlet linux
    2
    0 Stimmen
    2 Beiträge
    192 Aufrufe
    FrankMF
    Schauen wir uns mal an, wie man die Container aktuell hält. In der postgres.container steht das hier (als Beispiel) [Container] Image=docker.io/library/postgres:17 AutoUpdate=registry Das AutoUpdate=registry ist die Voraussetzung, dass der Container aktualisiert werden darf. Mit diesem Befehl kann man sich anschauen, wie der Stand der DInge ist. root@debian-4gb-nbg1-2-forgejo:~# podman auto-update --dry-run UNIT CONTAINER IMAGE POLICY UPDATED forgejo-pod.service 6486189fb10c (postgres) docker.io/library/postgres:17 registry false forgejo-pod.service 7d5627e2d434 (forgejo) codeberg.org/forgejo/forgejo:11.0.1 registry false forgejo-pod.service 7fb26d4f8b58 (nginx) docker.io/library/nginx:latest registry false Podman hat aber standardmäßig einen systemd Dienst, der sich darum kümmert root@forgejo:/etc/containers/systemd# systemctl status podman-auto-update.service ○ podman-auto-update.service - Podman auto-update service Loaded: loaded (/usr/lib/systemd/system/podman-auto-update.service; enabled; preset: enabled) Active: inactive (dead) since Mon 2025-06-09 00:02:57 UTC; 12h ago Invocation: a098f0054b254a0888ee789200ac9507 TriggeredBy: ● podman-auto-update.timer Docs: man:podman-auto-update(1) Process: 68939 ExecStart=/usr/bin/podman auto-update (code=exited, status=0/SUCCESS) Process: 68947 ExecStartPost=/usr/bin/podman image prune -f (code=exited, status=0/SUCCESS) Main PID: 68939 (code=exited, status=0/SUCCESS) Mem peak: 14.4M CPU: 292ms Jun 09 00:02:55 forgejo systemd[1]: Starting podman-auto-update.service - Podman auto-update service... Jun 09 00:02:55 forgejo podman[68939]: 2025-06-09 00:02:55.368941 +0000 UTC m=+0.059687227 system auto-update Jun 09 00:02:57 forgejo podman[68939]: UNIT CONTAINER IMAGE POLICY UPDATED Jun 09 00:02:57 forgejo podman[68939]: forgejo-pod.service 6486189fb10c (postgres) docker.io/library/postgres:17 registry false Jun 09 00:02:57 forgejo podman[68939]: forgejo-pod.service 7d5627e2d434 (forgejo) codeberg.org/forgejo/forgejo:11.0.1 registry false Jun 09 00:02:57 forgejo podman[68939]: forgejo-pod.service f2e9eee72017 (nginx) docker.io/library/nginx:latest registry false Jun 09 00:02:57 forgejo systemd[1]: podman-auto-update.service: Deactivated successfully. Jun 09 00:02:57 forgejo systemd[1]: Finished podman-auto-update.service - Podman auto-update service. postgres Ok, die Container sollten automatisch aktualisiert werden. docker.io/library/postgres:17 Die Postgres DB ist auf die Version 17 festgezurrt. Aktuell ist root@forgejo:/etc/containers/systemd# podman exec postgres postgres --version postgres (PostgreSQL) 17.5 (Debian 17.5-1.pgdg120+1) Eine Version 17.6 wird jetzt automatisch installiert, eine Version 18 aber nicht. nginx docker.io/library/nginx:latest NGINX zieht sich also immer die letzte "latest" Version, die zur Verfügung gestellt wird. root@forgejo:/etc/containers/systemd# podman exec nginx nginx -v nginx version: nginx/1.27.5 Gerade mal gecheckt, 1.27.5 ist die letzte Mainline Version. Also sind wir aktuell. forgejo Der Eintrag codeberg.org/forgejo/forgejo:11.0.1 aktuelle Version, die installiert ist. root@forgejo:/etc/containers/systemd# podman exec forgejo forgejo -v Forgejo version 11.0.1+gitea-1.22.0 (release name 11.0.1) built with GNU Make 4.4.1, go1.24.2 : bindata, timetzdata, sqlite, sqlite_unlock_notify Ok, wir sind auf Version 11.0.1 Wenn jetzt die Version 11.0.2 herauskommt, wird diese nicht installiert, da wir im forgejo.container folgendes stehen haben. [Container] Image=codeberg.org/forgejo/forgejo:11.0.1 Das ist aber erst mal nicht so schlimm, ich lese da mit und bekomme das mit. Das mache ich auch lieber von Hand, dann kann ich besser sehen wo es klemmt
  • Proxmox Setup 2025

    Proxmox proxmox linux
    1
    3
    0 Stimmen
    1 Beiträge
    205 Aufrufe
    Niemand hat geantwortet
  • Nextcloud - Update 31.0.2

    Nextcloud nextcloud linux
    1
    0 Stimmen
    1 Beiträge
    166 Aufrufe
    Niemand hat geantwortet
  • Update 1.33.1

    Vaultwarden vaultwarden linux
    1
    0 Stimmen
    1 Beiträge
    153 Aufrufe
    Niemand hat geantwortet
  • HSTS - Sicherheitsmechanismus für HTTPS-Verbindungen

    Linux hsts linux https
    1
    0 Stimmen
    1 Beiträge
    118 Aufrufe
    Niemand hat geantwortet
  • Manjaro Stable-Update vom 20.02.23

    Linux manjaro docker linux
    2
    0 Stimmen
    2 Beiträge
    200 Aufrufe
    FrankMF
    Ich konnte es nicht lassen, ich habe es mal getestet.    ~  docker version  ✔  1m 37s  Client: Version: 23.0.1 API version: 1.42 Go version: go1.20 Git commit: a5ee5b1dfc Built: Sat Feb 11 13:58:04 2023 OS/Arch: linux/amd64 Context: default In der aktuellen systemd Datei steht folgendes drin. Bei mir zu finden unter /usr/lib/systemd/system/docker.service LimitNOFILE=infinity LimitNPROC=infinity LimitCORE=infinity Die override Dateien angelegt und durchgestartet. Läuft alles einwandfrei. Aber bitte fragt mich nicht, was dieser Wert da oben macht. Ich habe keine Ahnung. Update: Erklärung zu ulimits https://stackoverflow.com/questions/62127643/need-understand-ulimits-nofile-setting-in-host-and-container
  • Restic v0.12.1 released

    Restic restic
    1
    0 Stimmen
    1 Beiträge
    194 Aufrufe
    Niemand hat geantwortet
  • Kopia - HTTP/S Server aufsetzen

    Angeheftet Kopia kopia linux
    1
    0 Stimmen
    1 Beiträge
    514 Aufrufe
    Niemand hat geantwortet