Skip to content

Rest-Server aufsetzen

Angeheftet Restic
  • Heute mal was Zeit gehabt um das erlernte Wissen über einen Rest-Server, praktisch mal umzusetzen.

    Schnappen wir uns einen virtuellen Server mit installiertem Debian Buster. Wie einige wissen, setze ich seit längerem auf die Hetzner Cloud.

    Gut, Debian Buster 10.4 haben sie noch nicht, also als erstes nach der Installation ein

    apt update && apt upgrade
    

    Danach neustarten!

    Download Rest-Server und installieren

    Im Github Repositorie den aktuellen Release suchen. Hier am Beispiel der aktuellen Version 0.12.0 (29.04.2023) Datei herunterladen

    wget https://github.com/restic/rest-server/releases/download/v0.12.0/rest-server_0.12.0_linux_amd64.tar.gz
    

    Die Datei entpacken

    tar -xf rest-server_0.12.0_linux_amd64.tar.gz
    

    Ins Verzeichnis wechseln

    cd rest-server_0.12.0_linux_amd64
    cp rest-server /usr/local/bin
    

    Danch kann man den Rest-Server benutzen

    rest-server -h
    Run a REST server for use with restic
    
    Usage:
      rest-server [flags]
    
    Flags:
          --append-only            enable append only mode
          --cpu-profile string     write CPU profile to file
          --debug                  output debug messages
      -h, --help                   help for rest-server
          --htpasswd-file string   location of .htpasswd file (default: "<data directory>/.htpasswd)"
          --listen string          listen address (default ":8000")
          --log filename           write HTTP requests in the combined log format to the specified filename
          --max-size int           the maximum size of the repository in bytes
          --no-auth                disable .htpasswd authentication
          --no-verify-upload       do not verify the integrity of uploaded data. DO NOT enable unless the rest-server runs on a very low-power device
          --path string            data directory (default "/tmp/restic")
          --private-repos          users can only access their private repo
          --prometheus             enable Prometheus metrics
          --prometheus-no-auth     disable auth for Prometheus /metrics endpoint
          --tls                    turn on TLS support
          --tls-cert string        TLS certificate path
          --tls-key string         TLS key path
      -v, --version                version for rest-server
    

    Installation rest-server (selbst bauen!)

    apt install git
    apt install golang-go
    git clone https://github.com/restic/rest-server.git
    cd rest-server
    go run build.go
    cp rest-server /usr/local/bin
    

    Danach können wir mit dem rest-server arbeiten.

    root@rest-server:~# rest-server -h
    Run a REST server for use with restic
    
    Usage:
      rest-server [flags]
    
    Flags:
          --append-only          enable append only mode
          --cpu-profile string   write CPU profile to file
          --debug                output debug messages
      -h, --help                 help for rest-server
          --listen string        listen address (default ":8000")
          --log string           log HTTP requests in the combined log format
          --max-size int         the maximum size of the repository in bytes
          --no-auth              disable .htpasswd authentication
          --path string          data directory (default "/tmp/restic")
          --private-repos        users can only access their private repo
          --prometheus           enable Prometheus metrics
          --tls                  turn on TLS support
          --tls-cert string      TLS certificate path
          --tls-key string       TLS key path
      -V, --version              output version and exit
    

    Ich möchte einen User habe, unter dem der rest-server später läuft.

    useradd rest-server -M
    

    Sollte selbst erklärend sein.

    SystemD

    Damit der Server auch ordentlich gestartet wird usw. legen wir einen systemd Dienst an.

    nano /etc/systemd/system/rest-server.service
    

    Inhalt der Datei

     [Unit]
     Description=Rest Server
     After=syslog.target
     After=network.target
     
     [Service]
     Type=simple
     User=rest-server
     Group=rest-server
     ExecStart=/usr/local/bin/rest-server --private-repos --tls --tls-cert /etc/letsencrypt/live/DOMAIN/fullchain.pem --tls-key /etc/letsencrypt/live/DOMAIN/privkey.pem --path /home/rest-server
     Restart=always
     RestartSec=5
     
     [Install]
     WantedBy=multi-user.target
    

    Aktivieren

    chmod +x rest-server.service
    systemctl enable rest-server.service
    

    Noch können wir den Server nicht starten. Uns fehlt noch das Zertifikat. Aber hiermit würde man das dann machen.

    systemctl start rest-server.service
    systemctl status rest-server.service
    systemctl stop rest-server.service
    

    Letsencrypt

    Installation

    apt install letsencrypt
    

    Zertifikat erstellen

    certbot certonly --standalone -d DOMAIN
    

    Crontab

    # m h  dom mon dow   command
    * 3  1 * * certbot renew --post-hook "chown -R rest-server:root /etc/letsencrypt/"
    

    Problem, der User rest-server konnte die Zertifikate nicht lesen!

    Die Zertifikate liegen in /etc/letsencrypt/live/DOMAIN

    Nach

    chown -R rest-server:root /etc/letsencrypt/
    

    war das Problem gelöst, da der User rest-server jetzt die Zertifikate lesen kann und der Server damit startet! Um bei einer Erneuerung der Zertifikate keine Probleme zu bekommen, habe ich im crontab folgendes ergänzt.

    --post-hook "chown -R rest-server:root /etc/letsencrypt/"
    

    Nach dem Aktualisieren, sollten die Benutzerrechte wieder angepasst werden. Sollte man das eleganter lösen können, oder ich hier einen Denkfehler haben, bitte ich um einen Kommentar. Danke!

    User Verwaltung

    Ich möchte einzelne User haben, die ein eigenes Verzeichnis haben. Denkt an einzelne Server, die ihren eigenen Platz haben und ihren eigenen Login!

    Beispiel

    • User: server1
    • PW: PASSWORD
    • Pfad: /home/rest-server/server1

    Verzeichnis erstellen

    mkdir /home/rest-server/server1
    chown rest-server:rest-server /home/rest-server/server1
    

    Im Verzeichnis /home/rest-server liegt eine .htpasswd zur Verwaltung der Benutzer.

    Installation

    apt install apache2-utils
    

    User anlegen

    Beim ersten Mal!

    htpasswd -B -c .htpasswd server1
    

    Beim zweiten User das -c weglassen!

    -c
    Create the passwdfile. If passwdfile already exists, it is rewritten and truncated.

    Zugriff auf den Rest-Server

    restic -r rest:https://USER:PASSWORD@DOMAIN:8000/server1 init
    

    Sicherheit

    Denkt an die grundlegenden Dinge wie

    • iptables
    • fail2ban
    • usw.

    Viel Spaß mit dem zentralen Ablageort für Eure verschlüsselten Backups!

    Quellen

    https://restic.net/
    https://restic.readthedocs.io/en/latest/030_preparing_a_new_repo.html#rest-server
    https://github.com/restic/rest-server

  • Nun, damit das Ganze Sinn macht, muss das automatisiert werden. Dazu brauchen wir ein Script. Hier mein Beispiel Script, was meine Redis Datenbank sichert.

    #!/bin/bash
    # Script um mit Restic Daten automatisiert zu sichern!
    # Dient zum Sichern der Redis-Datenbank auf den REST-Server!
    user=USER
    password=PASSWORD
    
    # Was soll gesichert werden?
    backup_pfad=/var/lib/redis/dump.rdb
    
    # Programm Start
    restic --password-file /root/passwd -r rest:https://$user:$password@DOMAIN:8000/redis backup $backup_pfad > redis.log
    restic --password-file /root/passwd -r rest:https://$user:$password@DOMAIN:8000/redis forget --keep-last 3 --keep-monthly 3 --prune >> redis.log
    
    # Testen
    restic --password-file /root/passwd -r rest:https://$user:$password@DOMAIN:8000/redis check --read-data >> redis.log
    
    #Ergebnis überwachen & Mail verschicken!
     if [ $? -eq 0 ]
     then
             echo "Backup Redis Dump erfolgreich!" | mailx -A redis.log -s "Backup Redis Dump erfolgreich!" USER@t-online.de
     else
             echo "Backup Redis Dump ***nicht erfolgreich!***" | mailx -A redis.log -s "Backup Redis Dump ***nicht erfolgreich!***" USER@t-online.de
     fi
    

    #Ergebnis überwachen & Mail verschicken!
    if [ $? -eq 0 ]
    then
    uuencode redis.log redis.log | mail -s "Backup Redis Dump erfolgreich!" USER@t-online.de
    else
    uuencode redis.log redis.log | mail -s "Backup Redis Dump nicht erfolgreich!" USER@t-online.de

    In Zeile 4 und 5 wird der User und das Passwort für den Zugriff auf den Restserver festgelegt.
    In /root/passwd liegt das Passwort für die Datensicherung

    Die erste Restic Zeile startet den Backup Vorgang und schreibt die Ausgabe ins Logfile redis.log

    Die zweite Restic Zeile dient dazu aufzuräumen. Es wird nur eine bestimmte Anzahl an Daten behalten. Lest dazu bitte in der Restic Dokumentation nach. Die Ausgabe wird ans Logfile redis.log angehangen.

    Die dritte Restic Zeile testet die Daten. Das sollte man bei großen Datenbeständen evt. nicht so oft machen, dauert usw. Ist mehr oder weniger optional. Wer es braucht... 🙂 Die Ausgabe wird in redis.log angehangen.

    Am Schluss wird das Ergebnis ausgewertet und eine Mail verschickt incl. Logfile.

    Zum Thema Mail verschicken -> https://forum.frank-mankel.org/topic/705/mail-vom-nas-verschicken?_=1589312591356

    Für das Tool uuencode muss das Paket sharutils installiert sein.

    apt install sharutils

    Und so sieht dann das Log aus, welches man per Mail geschickt bekommt.

    Files:           0 new,     1 changed,     0 unmodified
    Dirs:            0 new,     3 changed,     0 unmodified
    Added to the repo: 13.428 MiB
    
    processed 1 files, 20.282 MiB in 0:00
    snapshot 347c8f35 saved
    Applying Policy: keep the last 3 snapshots, 3 monthly snapshots
    snapshots for (host [debian-4gb-nbg1-1-webserver2], paths [/var/lib/redis/dump.rdb]):
    
    keep 3 snapshots:
    ID        Time                 Host                          Tags        Reasons           Paths
    ------------------------------------------------------------------------------------------------------------------
    12ec1c92  2020-05-13 09:11:59  debian-4gb-nbg1-1-webserver2              last snapshot     /var/lib/redis/dump.rdb
    8d24938e  2020-05-13 09:14:11  debian-4gb-nbg1-1-webserver2              last snapshot     /var/lib/redis/dump.rdb
    347c8f35  2020-05-13 09:17:47  debian-4gb-nbg1-1-webserver2              last snapshot     /var/lib/redis/dump.rdb
                                                                             monthly snapshot
    ------------------------------------------------------------------------------------------------------------------
    3 snapshots
    
    remove 1 snapshots:
    ID        Time                 Host                          Tags        Paths
    ------------------------------------------------------------------------------------------------
    7ad6f01a  2020-05-13 09:11:05  debian-4gb-nbg1-1-webserver2              /var/lib/redis/dump.rdb
    ------------------------------------------------------------------------------------------------
    1 snapshots
    
    1 snapshots have been removed, running prune
    counting files in repo
    building new index for repo
    [0:00] 100.00%  10 / 10 packs
    
    repository contains 10 packs (28 blobs) with 33.714 MiB
    processed 28 blobs: 0 duplicate blobs, 0 B duplicate
    load all snapshots
    find data that is still in use for 3 snapshots
    [0:00] 100.00%  3 / 3 snapshots
    
    found 28 of 28 data blobs still in use, removing 0 blobs
    will remove 0 invalid files
    will delete 0 packs and rewrite 0 packs, this frees 0 B
    counting files in repo
    [0:00] 100.00%  10 / 10 packs
    
    finding old index files
    saved new indexes as [4f2bfbd5]
    remove 2 old index files
    done
    using temporary cache in /tmp/restic-check-cache-850242223
    created new cache in /tmp/restic-check-cache-850242223
    create exclusive lock for repository
    load indexes
    check all packs
    check snapshots, trees and blobs
    read all data
    [0:00] 100.00%  10 / 10 items
    
    duration: 0:00
    no errors were found
    
  • Mir gefiel die Ausgabe auf meinem Handy nicht. Da kam mit dem K9 Mail Client nur das hier.

    Screenshot_20200515-080556.png

    Nicht schön. Kurze Suche im Netz und mal wieder festgestellt, das es auf Linux immer sehr viele Wege geht ein Problem zu lösen 🙂

    Wir nutzen dann ab jetzt mailx und das Tool uuencode wird damit überflüssig.

     #Ergebnis überwachen & Mail verschicken!
     if [ $? -eq 0 ]
     then
             echo "Backup Redis Dump erfolgreich!" | mailx -A redis.log -s "Backup Redis Dump erfolgreich!" USER@t-online.de
     else
             echo "Backup Redis Dump ***nicht erfolgreich!***" | mailx -A redis.log -s "Backup Redis Dump ***nicht erfolgreich!***" USER@t-online.de
     fi
    

    Das ganze hat was mit den MIME Format zu tuen. Mailx scheint das bessere und modernere Tool zu sein. Bitte nicht auf die Goldwaage legen, bin im Bereich Mail eine Null 🙂

    Ich kann aber jetzt auch auf meinem Handy das Log vernünftig lesen. Und das war das Ziel.

    Ich habe den vorhergehenden Beitrag entsprechend geändert!

  • Einen Monat später, kann ich berichten das die ganze Sache sehr rund läuft. In der ganzen Zeit hatte ich ein kleines Problem, das ich auf ein Netzwerkproblem bei Hetzner geschoben habe. Ich konnte es mir anders nicht erklären, ist aber bis heute auch nicht mehr passiert. Seit dem werden Tag für Tag die Backups angelegt 🙂

  • Hier mal ein Auszug aus meiner Mail, wie das so nach längerer Zeit aussieht.

    Applying Policy: keep the last 3 snapshots, 3 monthly snapshots
    snapshots for (host [debian-4gb-nbg1-1-webserver2], paths [/var/lib/redis/dump.rdb]):
    
    keep 5 snapshots:
    ID        Time                 Host                          Tags        Reasons           Paths
    ------------------------------------------------------------------------------------------------------------------
    48964ce8  2020-05-31 04:00:01  debian-4gb-nbg1-1-webserver2              monthly snapshot  /var/lib/redis/dump.rdb
    f9ae11c6  2020-06-30 04:00:01  debian-4gb-nbg1-1-webserver2              monthly snapshot  /var/lib/redis/dump.rdb
    ee45f569  2020-07-09 04:00:01  debian-4gb-nbg1-1-webserver2              last snapshot     /var/lib/redis/dump.rdb
    69aa517b  2020-07-10 04:00:01  debian-4gb-nbg1-1-webserver2              last snapshot     /var/lib/redis/dump.rdb
    9720d6ab  2020-07-11 04:00:01  debian-4gb-nbg1-1-webserver2              last snapshot     /var/lib/redis/dump.rdb
                                                                             monthly snapshot
    ------------------------------------------------------------------------------------------------------------------
    5 snapshots
    

    Hier kann man jetzt auch mal sehen, was der Befehl

    restic --password-file /root/passwd -r rest:https://$user:$password@DOMAIN:8000/redis forget --keep-last 3 --keep-monthly 3 --prune >> redis.log
    

    so macht. Man erhält also am Ende eines Monates jeweils ein Backup, in der Summe dann später drei Stück. Und von den letzten drei Tagen. Das sollte für das was ich mache völlig ausreichend sein.

  • Heute habe ich es doch mal geschafft, meine Nextcloud Installation zu schrotten. Ok, dafür hat man ja die ganzen Backups 🙂

     restic --password-file /root/passwd -r rest:https://$user:$password@DOMAIN:PORT/ORDNER restore e06b3571 -i /........path........./nextcloud --target /root/restore
    

    So macht man das 😉

    Als erstes brauchen wir die Snapshot ID

    restic --password-file /root/passwd -r rest:https://$user:$password@DOMAIN:PORT/ORDNER list snapshots
    

    Ich schaue auch gerne in meine EMails rein, da finde ich die Richtige. Wenn ich die habe, schaue ich mir den Inhalt an.

     restic --password-file /root/passwd -r rest:https://$user:$password@DOMAIN:PORT/ORDNER ls Snapshot_ID
    

    Dann suche ich mir das raus, was ich brauche. Mit

    -i /home/frank/
    

    würde man dann z.B. den Ordner /home/frank/ restoren. Am Ende gebe ich noch ein Ziel an, hier /root/restore

    Das hat perfekt geklappt. Hat sich der Rest-Server für mich schon gelohnt 🙂

  • Hallo Frank,

    erstmal vielen Dank für deine Erfahrungen, welche du hier so zusammenträgst. Dank deiner Threads bin ich auch über restic gestolpert und habe eine Test-VM (Debian11, restic per REST-Server via https) aufgesetzt. Meine Clients (Windows und Debian) können bereits automatisiert per Skript ihre Daten übertragen. Ich würde nun gern den Rest-Server im append-only Modus betreiben. Die Clients sind also nun nicht mehr in der Lage alte Snapshots zu entfernen. Wie würdest du das autom. Aufräumen im append-only Modus bewerkstellgen, wenn den Clients diesen Recht genommen wird?

  • @M8X Hallo und Willkommen.

    Eine sehr interessante Frage. Da ich das so nicht nutze, muss ich jetzt ein wenig spekulieren.

    Die Daten liegen ja im Verzeichnis auf dem Server. Jeder User, mit den nötigen Rechten, sollte auf diesem Server auf die Repos zugreifen können (PW des Repos vorausgesetzt)

    Somit sollte sich das ja gut mit einem Cronjob lösen lassen!?

  • @FrankM

    Hallo Frank,

    vielen Dank für deine Antwort. Die Clients greifen alle via REST-Schnittstelle auf den restic-Server zu. Da der restic-Server im append-only Modus läuft, können die Clients prinzipiell keine Snapshots entfernen, ihnen fehlt das Recht.

    Derzeit teste ich ein lokales, auf dem REST-Server liegendes Skript, welches per cron ausgeführt wird. Dieses Skript stellt eine lokale Verbindung zum REPO her, also nicht über die REST-Schnittstelle. Damit würde erstmal das Löschen älterer Snapshots funktionieren. Vielleicht hat ja noch jemand eine andere Idee??

  • Restic v0.16.0 released

    Restic
    1
    0 Stimmen
    1 Beiträge
    106 Aufrufe
    Niemand hat geantwortet
  • Restic - Migrate

    Restic
    1
    0 Stimmen
    1 Beiträge
    202 Aufrufe
    Niemand hat geantwortet
  • Restic v0.14.0 released

    Restic
    5
    0 Stimmen
    5 Beiträge
    160 Aufrufe
    FrankMF

    @berthold GUI v1.5.0 released mit Unterstützung für restic 0.14.0 und dem Migrations Tool. Bitte zum Testen evt. nicht auf die wichtigsten Daten loslassen 😉

    Mein Test mit meinem Repo auf dem REST-Server war erfolgreich.

  • Restic - Kompression

    Restic
    2
    0 Stimmen
    2 Beiträge
    300 Aufrufe
    FrankMF

    Gestern Abend noch ein paar Tests gemacht, aber nicht wirklich Erfolg gehabt. Ok, dann heute noch mal von vorne und mit System. Als erstes muss man mal Daten finden, die man auch gut komprimieren kann, ich will ja auch ein deutliches Ergebnis sehen.

    Meine Wahl fiel auf einen openwrt Ordner, mit dem ich mal ein Image selber gebaut hatte. Schön viele kleine Dateien, sollte sich gut komprimieren lassen.

    Original

    547e3596-69df-48ac-9409-5173367afb85-grafik.png

    Test mit 7z

    Rechtsklick, mit den Bordmittel und dann 7z gewählt.

    364b497f-cf59-408c-ba2b-cad70cc09529-grafik.png

    Test mit Restic V1

    Ich habe auf einer mechanischen 1TB Platte zwei Ordner angelegt, einmal Restic_V1, einmal Restic_V2.

    frank@frank-MS-7C37:~/Downloads$ restic version restic 0.13.1 compiled with go1.18 on linux/amd64 Init restic init -r /media/1TB/Restic_V1/ Backup frank@frank-MS-7C37:~/Downloads$ restic -r /media/1TB/Restic_V1/ backup /home/frank/openwrt/ enter password for repository: repository 731db857 opened successfully, password is correct created new cache in /home/frank/.cache/restic no parent snapshot found, will read all files Files: 407839 new, 0 changed, 0 unmodified Dirs: 41286 new, 0 changed, 0 unmodified Added to the repo: 7.851 GiB processed 407839 files, 11.061 GiB in 4:49 snapshot 24cd8ef4 saved Ergebnis

    799fa3ee-5bdf-48ba-a05e-8f7f24f1c41b-grafik.png

    Test mit Restic V2 frank@frank-MS-7C37:~/Downloads$ ./restic_v0.13.0-126-g26c33332_linux_amd64 version restic 0.13.1-dev (compiled manually) compiled with go1.18 on linux/amd64 Init ./restic_v0.13.0-126-g26c33332_linux_amd64 init -r /media/1TB/Restic_V2/ --repository-version 2 Backup frank@frank-MS-7C37:~/Downloads$ ./restic_v0.13.0-126-g26c33332_linux_amd64 -r /media/1TB/Restic_V2/ backup /home/frank/openwrt/ enter password for repository: repository 33c5e24c opened (repo version 2) successfully, password is correct created new cache in /home/frank/.cache/restic no parent snapshot found, will read all files Files: 407839 new, 0 changed, 0 unmodified Dirs: 41286 new, 0 changed, 0 unmodified Added to the repo: 7.835 GiB processed 407839 files, 11.061 GiB in 2:47 snapshot 474d0376 saved Ergebnis

    caafd946-1285-4e1d-8873-a3ff4141a777-grafik.png

    Fazit

    Fassen wir es mal ein wenig zusammen. Das Original hat 12,1GB

    ITool Dateigröße Zeit 7z 2,2GB ca. 11:59 Restic V1 8,5GB 4:49 Restic V2 2,9GB 2:47

    Man kann auch noch etwas an der Kompression einstellen, ich habe es für diesen Test auf der Standardeinstellung(?) gelassen.

    You can set the desired compression level by passing it to --compression (e.g. restic backup --compression max), supported are auto, max and off.

    Das Ergebnis sieht sehr vielversprechend aus. Es könnte den Platzverbrauch stark begrenzen, sehr wichtig für mich wenn man seine Daten in einer Cloud speichert. (Stichwort: Kosten) Und was hier auch noch schön ins Auge fällt, es ist schneller 🙂 Das möchte ich hier nicht versuchen zu erklären, da ich nicht genau woran es liegt. Vermutung, ich muss wesentlich weniger Daten "schreiben".

    Ich freue mich extrem, diese Version produktiv einzusetzen. Mal überlegen, ob ich die Version hier auf dem Haupt-PC mal testweise nutze, ich denke das wäre spannend.

    @Restic-Team: Vielen Dank für dieses tolle Feature!
  • Restic - Passwortübergabe

    Restic
    1
    0 Stimmen
    1 Beiträge
    174 Aufrufe
    Niemand hat geantwortet
  • Rest-Server

    Verschoben Restic
    8
    0 Stimmen
    8 Beiträge
    559 Aufrufe
    FrankMF

    Dann mal eben ausprobiert. Auf meinem Server war die Version 0.9.7 selber, mit go, gebaut. Dann mache ich das auch mit der v0.10.0 so. Aber bevor ich anfange, wird die v0.9.7 gesichert.

    mv /usr/local/bin/rest-server /usr/local/bin/rest-server_0_9_7

    So erspare ich mir im Problemfall das selber bauen.

    Ok, dann die neue Version bauen.

    git clone https://github.com/restic/rest-server.git cd rest-server go run build.go

    Danach befindet sich im Verzeichnis die Binärdatei rest-server

    Die kopieren wir jetzt

    cp rest-server /usr/local/bin

    Danach kurzer Test

    # rest-server --version rest-server 0.10.0 (v0.10.0-6-g037fe06) compiled with go1.11.6 on linux/amd64

    Gut Version passt 🙂

    Dann ein Backup gestartet. Das sichert einen Teil meines Home-Verzeichnis

    Files: 153 new, 100 changed, 177857 unmodified Dirs: 0 new, 1 changed, 0 unmodified Added to the repo: 81.881 MiB processed 178110 files, 80.571 GiB in 0:28 snapshot 607e0027 saved Applying Policy: keep the last 3 snapshots, 3 monthly snapshots keep 5 snapshots: ID Time Host Tags Reasons Paths --------------------------------------------------------------------------------------- fa97890e 2020-07-25 21:02:05 frank-XXX monthly snapshot /home/frank 5b073bbb 2020-08-30 10:17:27 frank-XXX monthly snapshot /home/frank f7cf37ef 2020-09-06 15:13:03 frank-XXX last snapshot /home/frank 0157462c 2020-09-13 13:32:12 frank-XXX last snapshot /home/frank 607e0027 2020-09-14 08:09:34 frank-XXX last snapshot /home/frank monthly snapshot --------------------------------------------------------------------------------------- 5 snapshots remove 1 snapshots: ID Time Host Tags Paths --------------------------------------------------------------------- 3010b7cc 2020-09-06 11:39:27 frank-XXX /home/frank --------------------------------------------------------------------- 1 snapshots 1 snapshots have been removed, running prune counting files in repo building new index for repo [1:34] 100.00% 17351 / 17351 packs

    So weit funktioniert das genau wie vorher. Im Changelog stand ja was von Subfoldern. Das betrifft mich nicht, weil ich für jeden User genau ein Verzeichnis habe.

    So mit alles Gut 🙂 Dann warte ich mal morgen ab, ob die täglichen Backups der Server rund laufen.

  • Restic - forget --keep-last 3 --prune

    Restic
    2
    0 Stimmen
    2 Beiträge
    600 Aufrufe
    FrankMF

    Ich habe mich damit noch ein wenig beschäftigt, die letzten drei zu behalten, ist nicht so optimal. Da es viele Optionen bei dem Befehl gibt, hier ein Ausschnitt

    Flags: -l, --keep-last n keep the last n snapshots -H, --keep-hourly n keep the last n hourly snapshots -d, --keep-daily n keep the last n daily snapshots -w, --keep-weekly n keep the last n weekly snapshots -m, --keep-monthly n keep the last n monthly snapshots -y, --keep-yearly n keep the last n yearly snapshots

    habe ich das ein wenig so angepasst, das ich denke es passt für mich.

    restic --password-file /root/passwd -r /media/NAS_neu/Restic/Home/ forget --keep-last 3 --keep-monthly 3 --prune

    Damit behalte ich auch die jeweils eines pro Monat. Und die letzten drei. Das sieht dann so aus.

    root@debian:~# ./backup2.sh repository 2f3f6147 opened successfully, password is correct Files: 38 new, 100 changed, 13268 unmodified Dirs: 0 new, 1 changed, 0 unmodified Added to the repo: 10.166 GiB processed 13406 files, 50.324 GiB in 3:24 snapshot 849f614c saved repository 2f3f6147 opened successfully, password is correct Applying Policy: keep the last 3 snapshots, 3 monthly snapshots snapshots for (host [debian], paths [/home/frank]): keep 5 snapshots: ID Time Host Tags Reasons Paths ------------------------------------------------------------------------------------ a7251cfd 2019-11-28 17:00:01 debian monthly snapshot /home/frank 283d4027 2019-12-31 17:00:01 debian monthly snapshot /home/frank ae2b96ec 2020-01-01 21:47:46 debian last snapshot /home/frank 079e00a6 2020-01-02 17:00:01 debian last snapshot /home/frank 849f614c 2020-01-03 21:08:45 debian last snapshot /home/frank monthly snapshot ------------------------------------------------------------------------------------ 5 snapshots remove 26 snapshots: ID Time Host Tags Paths ------------------------------------------------------------------ 896f16c2 2019-11-07 22:23:40 debian /home/frank b21bcf6d 2019-11-11 17:00:01 debian /home/frank f89248fb 2019-11-12 17:00:01 debian /home/frank 123ab546 2019-11-13 17:00:01 debian /home/frank b82d87d0 2019-11-18 17:00:01 debian /home/frank 040b0ab7 2019-11-19 17:00:01 debian /home/frank 7221d8ef 2019-11-20 17:00:01 debian /home/frank 84132a25 2019-11-21 17:00:01 debian /home/frank b558a52c 2019-11-25 17:00:01 debian /home/frank e5cc0c3e 2019-12-02 17:00:01 debian /home/frank 22423fa5 2019-12-03 17:00:01 debian /home/frank 39df1ab9 2019-12-04 17:00:01 debian /home/frank 98843457 2019-12-05 17:00:01 debian /home/frank b0cdd4b6 2019-12-09 17:00:01 debian /home/frank 828414f9 2019-12-10 17:00:01 debian /home/frank e34a27c3 2019-12-11 17:00:01 debian /home/frank 6e488c3b 2019-12-12 17:00:01 debian /home/frank 17898403 2019-12-16 17:00:01 debian /home/frank 1973305a 2019-12-17 17:00:01 debian /home/frank 9553bedd 2019-12-18 17:00:01 debian /home/frank fedf749d 2019-12-19 17:00:01 debian /home/frank 8e7cb876 2019-12-23 17:00:01 debian /home/frank 0bd0d102 2019-12-25 17:00:01 debian /home/frank 13d348b0 2019-12-26 17:00:01 debian /home/frank c7d960aa 2019-12-30 17:00:01 debian /home/frank f6ea9118 2020-01-01 17:00:01 debian /home/frank ------------------------------------------------------------------ 26 snapshots 26 snapshots have been removed, running prune counting files in repo building new index for repo [0:35] 100.00% 7806 / 7806 packs repository contains 7806 packs (46537 blobs) with 41.110 GiB processed 46537 blobs: 0 duplicate blobs, 0 B duplicate load all snapshots find data that is still in use for 5 snapshots [0:01] 100.00% 5 / 5 snapshots found 32654 of 46537 data blobs still in use, removing 13883 blobs will remove 0 invalid files will delete 715 packs and rewrite 752 packs, this frees 5.027 GiB [2:28] 100.00% 752 / 752 packs rewritten counting files in repo [0:01] 100.00% 6571 / 6571 packs finding old index files saved new indexes as [d137b425 f7caee99 a6e9711a] remove 35 old index files [1:13] 100.00% 1467 / 1467 packs deleted done using temporary cache in /tmp/restic-check-cache-916655151 repository 2f3f6147 opened successfully, password is correct created new cache in /tmp/restic-check-cache-916655151 create exclusive lock for repository load indexes check all packs check snapshots, trees and blobs read all data [7:47] 100.00% 6571 / 6571 items duration: 7:47 no errors were found root@debian:~#

    Am Ende seht ihr noch, wie Restic alle Files testet. Mein Script sieht jetzt so aus.

    #!/bin/bash # Script um mit Restic Daten automatisiert zu sichern! # Dient zum Sichern der Homepartition auf dem ROCKPro64 NAS! # Was soll gesichert werden? backup_pfad=/home/frank # Programm Start restic --password-file /root/passwd -r /media/NAS_neu/Restic/Home/ backup $backup_pfad --exclude-file=excludes.txt restic --password-file /root/passwd -r /media/NAS_neu/Restic/Home/ forget --keep-last 3 --keep-monthly 3 --prune # Testen restic --password-file /root/passwd -r /media/NAS_neu/Restic/Home/ check --read-data

    Das dann schön mit einem Cronjob laufen lassen und die Datensicherung ist erledigt 😉

  • Restic - Update

    Restic
    1
    0 Stimmen
    1 Beiträge
    407 Aufrufe
    Niemand hat geantwortet