Skip to content
linux-nerds.org

linux-nerds.org
  1. Übersicht
  2. Linux
  3. Restic
  4. Restic - Ein Backupkonzept - Automatisieren!

Restic - Ein Backupkonzept - Automatisieren!

Verschoben Restic
  • FrankMF

    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!

    Im Fediverse -> @FrankM@nrw.social

    1. NanoPi R5S
    2. Quartz64 Model B, 4GB RAM
    3. Quartz64 Model A, 4GB RAM
    4. RockPro64 v2.1
    0

  • FrankMF

    KDE Plasma setzt auf Wayland

    Linux
    1
    0 Stimmen
    1 Beiträge
    61 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    ZFS - Wichtige Befehle

    Linux
    2
    0 Stimmen
    2 Beiträge
    625 Aufrufe
    FrankMF

    Unter dem Beitrag sammel ich mal ein paar Beispiele, für mich zum Nachlesen 🙂

    Den Anfang macht die

    ZFS-Replication

    Ich hatte Am Anfang ein wenig Verständnisprobleme, bis es klar war, das diese Replication von Pool zu Pool funktioniert. Also brauchen wir zwei vorhandene ZFS-Pools.

    root@pbs:/mnt/datastore/datapool/test# zfs list NAME USED AVAIL REFER MOUNTPOINT Backup_Home 222G 677G 222G /mnt/datastore/Backup_Home datapool 2.36G 1.75T 2.36G /mnt/datastore/datapool

    Wir erzeugen ein Dataset im datapool

    zfs create datapool/docs -o mountpoint=/docs

    Wir erzeugen eine Datei mit Inhalt

    echo "version 1" > /docs/data.txt

    Wir erzeugen einen Snapshot

    zfs snapshot datapool/docs@today

    Kontrolle

    root@pbs:/mnt/datastore/datapool/test# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT datapool/docs@today 0B - 96K -

    Wir replizieren den vorhandenen Snapshot zum ZFS-Pool Backup_Home und speichern ihn da im Dataset test.

    zfs send datapool/docs@today | zfs receive Backup_Home/test

    Nun befinden sich die Daten in dem anderen ZFS-Pool

    root@pbs:/mnt/datastore/datapool/test# ls /mnt/datastore/Backup_Home/test/ data.txt

    Und was mich am meisten interessiert, ist wie man das zu einem anderen Server schickt 😉

    zfs send datapool/docs@today | ssh otherserver zfs receive backuppool/backup

    Den Test reiche ich dann später nach.

    Quelle: https://www.howtoforge.com/tutorial/how-to-use-snapshots-clones-and-replication-in-zfs-on-linux/

    ZFS inkrementelle Replication

    Als, nur die geänderten Daten senden!

    Wir erzeugen ein paar Dateien

    root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data1.txt root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data2.txt root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data3.txt root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data4.txt

    Neuer Snapshot

    zfs snapshot datapool/docs@17:02

    Liste der Snapshots

    root@pbs:/mnt/datastore/datapool/test# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT datapool/docs@today 56K - 96K - datapool/docs@17:02 0B - 112K -

    Wir senden dieinkrementelle Replication

    zfs send -vi datapool/docs@today datapool/docs@17:02 | zfs receive Backup_Home/test send from datapool/docs@today to datapool/docs@17:02 estimated size is 38.6K total estimated size is 38.6K cannot receive incremental stream: destination Backup_Home/test has been modified since most recent snapshot

    Dazu schreibt die Anleitung, die ich unten verlinkt habe, das die Daten verändert wurden. Warum, verstehe ich aktuell noch nicht. Mit -F im send Befehl erzwingt man einen Rollback zum letzten Snapshot.

    zfs send -vi datapool/docs@today datapool/docs@17:02 | zfs receive -F Backup_Home/test send from datapool/docs@today to datapool/docs@17:02 estimated size is 38.6K total estimated size is 38.6K

    Und Kontrolle

    ls /mnt/datastore/Backup_Home/test/ data1.txt data2.txt data3.txt data4.txt data.txt

    Quelle: https://klarasystems.com/articles/introduction-to-zfs-replication/

  • FrankMF

    checkmk - Rest-Server überwachen

    Verschoben checkmk
    1
    0 Stimmen
    1 Beiträge
    445 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Ubiquiti ER-X - iperf

    Verschoben OpenWRT & Ubiquiti ER-X
    2
    0 Stimmen
    2 Beiträge
    273 Aufrufe
    FrankMF

    Hier noch ein Test von DMZ / LAN und andersrum.

    frank@frank-MS-7C37:~$ iperf3 -c 192.168.5.15 Connecting to host 192.168.5.15, port 5201 [ 5] local 192.168.3.213 port 44052 connected to 192.168.5.15 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 114 MBytes 952 Mbits/sec 314 153 KBytes [ 5] 1.00-2.00 sec 112 MBytes 937 Mbits/sec 259 205 KBytes [ 5] 2.00-3.00 sec 111 MBytes 929 Mbits/sec 210 212 KBytes [ 5] 3.00-4.00 sec 111 MBytes 934 Mbits/sec 235 202 KBytes [ 5] 4.00-5.00 sec 112 MBytes 936 Mbits/sec 263 153 KBytes [ 5] 5.00-6.00 sec 111 MBytes 935 Mbits/sec 255 209 KBytes [ 5] 6.00-7.00 sec 112 MBytes 937 Mbits/sec 313 129 KBytes [ 5] 7.00-8.00 sec 111 MBytes 932 Mbits/sec 296 209 KBytes [ 5] 8.00-9.00 sec 111 MBytes 934 Mbits/sec 258 208 KBytes [ 5] 9.00-10.00 sec 111 MBytes 934 Mbits/sec 292 201 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 936 Mbits/sec 2695 sender [ 5] 0.00-10.00 sec 1.09 GBytes 935 Mbits/sec receiver iperf Done. frank@frank-MS-7C37:~$ iperf3 -R -c 192.168.5.15 Connecting to host 192.168.5.15, port 5201 Reverse mode, remote host 192.168.5.15 is sending [ 5] local 192.168.3.213 port 44058 connected to 192.168.5.15 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 109 MBytes 911 Mbits/sec [ 5] 1.00-2.00 sec 109 MBytes 912 Mbits/sec [ 5] 2.00-3.00 sec 109 MBytes 912 Mbits/sec [ 5] 3.00-4.00 sec 109 MBytes 912 Mbits/sec [ 5] 4.00-5.00 sec 109 MBytes 912 Mbits/sec [ 5] 5.00-6.00 sec 108 MBytes 903 Mbits/sec [ 5] 6.00-7.00 sec 109 MBytes 912 Mbits/sec [ 5] 7.00-8.00 sec 109 MBytes 912 Mbits/sec [ 5] 8.00-9.00 sec 109 MBytes 912 Mbits/sec [ 5] 9.00-10.00 sec 109 MBytes 912 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.06 GBytes 913 Mbits/sec 114 sender [ 5] 0.00-10.00 sec 1.06 GBytes 911 Mbits/sec receiver iperf Done.
  • FrankMF

    Rest-Server aufsetzen

    Angeheftet Restic
    9
    0 Stimmen
    9 Beiträge
    2k Aufrufe
    M

    @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??

  • FrankMF

    Node.js installieren

    Linux
    1
    0 Stimmen
    1 Beiträge
    300 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    NodeBB - spawn npm ENOENT

    NodeBB
    1
    0 Stimmen
    1 Beiträge
    413 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    nginx konfigurieren

    NodeBB
    1
    0 Stimmen
    1 Beiträge
    631 Aufrufe
    Niemand hat geantwortet