Skip to content

Restic - Einen ROCKPro64 als Datengrab benutzen

Verschoben Restic
  • Idee

    Wir wollen Daten von unserem Haupt-PC auf einen ROCKPro64 sichern. Da unser Haupt-PC komplett verschlüsselt ist, wäre es dumm die Backups im Klartext abzulegen. Also muss die ganze Sache verschlüsselt erfolgen. Und da kommt denn Restic ins Spiel. Das Tool sichert die Daten und legt sie verschlüsselt ab. Damit der Datentransport sicher ist, nutzen wir SFTP für den Verbindungsaufbau. Sollte ausreichend sicher sein 😉

    Das geht natürlich nicht nur mit einem ROCKPro64, sondern auch mit einem RaspberryPi, BananaPi, normaler Server usw. Ich teste das nur mal um zu schauen, ob auf dem ROCKPro64 irgendwelche Fehler auftauchen.

    Das war jetzt das grobe Softwarekonzept.

    Hardware

    • Mein Haupt-PC
    • ROCKPro64 2GB
    • Betriebssystem SSD an USB3 (mit aktivem HUB)
    • PCIe SATA Adapter mit 1TB HDD (Datengrab)

    0_1534604019136_IMG_20180818_142519_ergebnis.jpg

    Software

    Eingesetztes Betriebssystem auf dem ROCKPro64

    rock64@rockpro64v2_1:~$ uname -a
    Linux rockpro64v2_1 4.4.132-1075-rockchip-ayufan-ga83beded8524 #1 SMP Thu Jul 26 08:22:22 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
    

    Nicht ganz aktuell 😉

    Eingesetztes Betriebssystem Haupt-PC

    frank@frank-MS-7A34 ~ $ uname -a
    Linux frank-MS-7A34 4.10.0-42-generic #46~16.04.1-Ubuntu SMP Mon Dec 4 15:57:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
    

    Ein Linux Mint Cinnamon, das muss auch mal aktualisiert werden. Da trifft sich das mit der Datensicherung ja ganz gut.

    Was brauchen wir an Tools?

    • golang
    • restic

    Kurze Erklärung, Restic basiert auf der Programmiersprache Go. Damit wir Restic nutzen können, müssen wir uns das Programm bauen und dazu brauchen wir Go.

    Installation Go

    sudo apt-get install golang
    

    Kontrolle

    rock64@rockpro64v2_1:~$ go version
    go version go1.10.1 linux/arm64
    

    Damit haben wir schon mal die Programmiersprache Go auf der Kiste.

    Installation restic

    git clone https://github.com/restic/restic
    cd restic
    go run build.go
    sudo cp restic /usr/bin
    

    Erklärung:

    1. Wir laden das Repository von github
    2. Wir wechseln in das Verzeichnis
    3. Wir bauen mit go die Anwendung restic
    4. Wir kopieren restic ins Verzeichnis /usr/bin

    Testen ob Restic läuft

    rock64@rockpro64v2_1:/$ restic version
    restic 0.9.2 (v0.9.2-34-g5a25ad19) compiled with go1.10.1 on linux/arm64
    

    Prima, so weit funktioniert alles.


    Zur Erinnerung, ich möchte das Home-Verzeichnis meines Haupt-PCs auf dem ROCKPro64 sichern.

    SSH

    Wir brauchen einen passwortlosen Zugriff auf den ROCKPro64. Ich gehe hier nicht so intensiv darauf ein, dazu gibt es viele andere Seiten im Netz.

    Wir kopieren den Key vom User root auf den ROCKPro64
    Wenn ihr noch keinen Key erzeugt habt, dann jetzt

    sudo su
    ssh-keygen
    

    Den erzeugten Key dann auf den ROCKPro64 kopieren.

    ssh-copy-id -i /root/.ssh/id_rsa.pub rock64@[IP RockPro64]
    

    Nach dem erfolgten Kopieren, muss man sich jetzt ohne Passwort einloggen können.

    ssh rock64@[IP RockPro]
    

    Wenn das klappt, ist alles bereit um mit Restic weiter zu machen.

    Restic

    Backup initialisieren!

    frank@frank-MS-7A34 ~ $ restic -r sftp:rock64@IP:/home/rock64/backup init
    enter password for new repository: 
    enter password again: 
    created restic repository 829d34fe54 at sftp:rock64@IP:/home/rock64/backup
    
    Please note that knowledge of your password is required to access
    the repository. Losing your password means that your data is
    irrecoverably lost.
    

    Unter /home/rock64/backup soll Restic die Daten ablegen. Man wird dazu nach einem Passwort gefragt, das ist extrem wichtig, weil damit die Daten verschlüsselt werden. Wenn man das vergisst, sind die Daten weg! Also, gut merken!!

    Backup anlegen

    frank@frank-MS-7A34 ~ $ sudo restic -r sftp:rock64@IP:/home/rock64/backup backup /home/frank --exclude={/Virtual*}
    [sudo] Passwort für frank: 
    The authenticity of host 'IP (IP)' can't be established.
    ECDSA key fingerprint is SHA256:OcOCxxxxxxxxxxxxxxxxxxxxxRevLyh4w.
    Are you sure you want to continue connecting (yes/no)? yes
    subprocess ssh: Warning: Permanently added 'IP' (ECDSA) to the list of known hosts.
    rock64@IP's password: 
    enter password for repository: 
    password is correct
    found 3 old cache directories in /home/frank/.cache/restic, pass --cleanup-cache to remove them
    scan [/home/frank]
    scanned 15965 directories, 158483 files in 0:01
    [22:27] 100.00%  111.352 GiB / 111.349 GiB  174454 / 174448 items  0 errors  ETA 0:00 
    duration: 22:27
    snapshot 073b7cb4 saved
    

    Was passiert hier?

    Ich möchte das Verzeichnis /home/frank sichern. Habe aber einige Instanzen von Virtual Box, die ich aktuell nicht mitsichern möchte.
    Das Passwort für den User frank wird abgefragt. Dann das Paswort für den ROCKPro64. Dann wird der SSH Key der Liste der bekannten Geräte hinzugefügt. Warum? Ich hatte vorher als User frank getestet, habe aber einige Zugriffsverletzungen bekommen.

    error for /home/frank/.cache/dconf: open /home/frank/.cache/dconf: permission denied
    error for /home/frank/.gvfs: open /home/frank/.gvfs: permission denied
    

    Ok, dann als Chef 🙂

    Dann fragt Restic nach dem Passwort das ihr hoffentlich noch wisst 😉 Jetzt fängt Restic an zu arbeiten. Als erstes räumt es ein wenig auf. Danach werden 111GB gesichert. Warum jetzt Restic? Zum einen ist es verschlüsselt und zum anderen wird bei dem nächsten Aufruf extrem effektiv gespeichert. Beispiel:

    frank-MS-7A34 home # restic -r sftp:rock64@192.168.3.207:/home/rock64/backup backup /home/frank --exclude={/Virtual*}
    enter password for repository: 
    password is correct
    using parent snapshot 073b7cb4
    scan [/home/frank]
    scanned 16212 directories, 159277 files in 0:01
    [0:16] 100.00%  111.494 GiB / 111.494 GiB  175491 / 175489 items  0 errors  ETA 0:00 
    duration: 0:16
    snapshot 6bc9b21b saved
    

    Ich hatte vorher ein paar Bilder dort abgelegt. Aber man sieht hier, es werden nur neue oder geänderte Daten gesichert. Somit ist das extrem effektiv. Das hat genau 16 Sekunden gedauert 🙂

    Verbesserungen

    Das alles habe ich jetzt auf die Betriebssystem SSD kopiert, nicht so toll. Da muss noch was schönes an die PCIe SATA Karte. Und dahin müssen dann die Daten. Aber das ist ja nicht so schwer, Pfad anpassen - Fertig!

    Das alles noch automatisieren.

    Mehr Infos zum Thema Restic? Bitte -> https://forum.frank-mankel.org/tags/restic

  • So, dann mal das Ganze testen wenn man seinen Haupt-PC neu installiert hat und ein paar Daten braucht.

    0_1534692578537_IMG_20180819_090116_ergebnis.jpg

    Also, mal Restic installiert.

    sudo apt-get install restic
    

    Nach erfolgter Installation ein Test

    frank@frank-MS-7A34:~/restic$ restic version
    restic 0.8.3
    compiled with go1.10 on linux/amd64
    

    Geht so weit.

    Snapshots auflisten.

    restic -r sftp:rock64@IP:/home/rock64/backup snapshots
    

    Sieht dann so aus.

     frank@frank-MS-7A34:~$ sudo restic -r sftp:rock64@192.168.3.207:/home/rock64/backup snapshots
     [sudo] Passwort für frank: 
     rock64@192.168.3.207's password: 
     enter password for repository: 
     password is correct
     ID        Date                 Host           Tags        Directory
     ----------------------------------------------------------------------
     7e2eddcb  2018-08-18 10:10:40  frank-MS-7A34              /home/frank/Bilder
     073b7cb4  2018-08-18 14:21:17  frank-MS-7A34              /home/frank
     6bc9b21b  2018-08-18 16:11:19  frank-MS-7A34              /home/frank
     ----------------------------------------------------------------------
     3 snapshots
    

    Snapshot wiederherstellen

    sudo restic -r sftp:rock64@IP:/home/rock64/backup restore latest --target /tmp/backup
    

    Hiermit stellen wir das Backup im temporären Ordner /tmp/backup wieder her. Hat ewig gedauert, aber ging !?!?!?

  • Ubuntu wird 20

    Linux
    1
    0 Stimmen
    1 Beiträge
    102 Aufrufe
    Niemand hat geantwortet
  • NAS 2023 - Thema Datensicherung

    Verschoben Linux
    2
    0 Stimmen
    2 Beiträge
    140 Aufrufe
    FrankMF

    Bleibt noch etwas wichtiges. Die ganzen Konfigurationsdateien vom Proxmox Host. Sinnvoll, das man sich das sichert.

    #!/bin/bash # Script um mit Restic Daten automatisiert zu sichern! # Dient zum Sichern des Ordners /etc/pve! # Was soll gesichert werden? backup_pfad=/etc/pve # Programm Start restic --password-file /root/passwd -r /mnt/pve/Restic_Backups/pve backup $backup_pfad > backup_pve_001.log restic --password-file /root/passwd -r /mnt/pve/Restic_Backups/pve forget --keep-last 3 --keep-monthly 3 --prune >> backup_pve_002.log # Testen restic --password-file /root/passwd -r /mnt/pve/Restic_Backups/pve check --read-data >> backup_pve_003.log

    Crontab eingerichtet - fertig!

  • NAS 2023 - Software Teil 2

    Angeheftet Verschoben Linux
    1
    0 Stimmen
    1 Beiträge
    198 Aufrufe
    Niemand hat geantwortet
  • Restic v0.14.0 released

    Restic
    5
    0 Stimmen
    5 Beiträge
    164 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.

  • Kopia

    Allgemeine Diskussionen
    1
    0 Stimmen
    1 Beiträge
    268 Aufrufe
    Niemand hat geantwortet
  • Kopia 0.7.0-rc1 Kurztest

    Kopia
    2
    0 Stimmen
    2 Beiträge
    317 Aufrufe
    FrankMF

    Nachdem ich doch ziemlich lange Snapshot Zeiten hatte, habe ich Jarek mal gefragt woran das liegt.

    I guess you could run it in the cloud but latency will be progressively worse
    because it's a chatty protocol sensitive to latency

    Technisch verstehe ich das nicht, aber ich habe dann mal als kurzen Test auf meine lokale SSD einen Snapshot gemacht. Der war nach 2 Minuten (ca. 11GB) fertig. Der zweite Snapshot brauchte ca. 12 Sekunden. Das hört sich schon mal viel besser an, als die Stunden.

    Aktuell ist der Plan den Kopia-Server im Internet zu nutzen damit beerdigt. Das scheint so nicht zu funktionieren. Ich mache da noch einen kurzen Test, diesmal Lokal auf meinem NAS.

  • LUKS verschlüsselte Platte mounten

    Linux
    2
    0 Stimmen
    2 Beiträge
    922 Aufrufe
    FrankMF

    So, jetzt das ganze noch einen Ticken komplizierter 🙂

    Ich habe ja heute, für eine Neuinstallation von Ubuntu 20.04 Focal eine zweite NVMe SSD eingebaut. Meinen Bericht zu dem Thema findet ihr hier. Aber, darum soll es jetzt hier nicht gehen.

    Wir haben jetzt zwei verschlüsselte Ubuntu NVMe SSD Riegel im System. Jetzt klappt die ganze Sache da oben nicht mehr. Es kommt immer einen Fehlermeldung.

    unbekannter Dateisystemtyp „LVM2_member“.

    Ok, kurz googlen und dann findet man heraus, das es nicht klappen kann, weil beide LVM Gruppen, den selben Namen benutzen.

    root@frank-MS-7C37:/mnt/crypthome/root# vgdisplay --- Volume group --- VG Name vgubuntu2 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size <464,53 GiB PE Size 4,00 MiB Total PE 118919 Alloc PE / Size 118919 / <464,53 GiB Free PE / Size 0 / 0 VG UUID lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A --- Volume group --- VG Name vgubuntu System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size <475,71 GiB PE Size 4,00 MiB Total PE 121781 Alloc PE / Size 121781 / <475,71 GiB Free PE / Size 0 / 0 VG UUID jRYTXL-zjpY-lYr6-KODT-u0LJ-9fYf-YVDna7

    Hier oben sieht man das schon mit geändertem Namen. Der VG Name muss unterschiedlich sein. Auch dafür gibt es ein Tool.

    root@frank-MS-7C37:/mnt/crypthome/root# vgrename --help vgrename - Rename a volume group Rename a VG. vgrename VG VG_new [ COMMON_OPTIONS ] Rename a VG by specifying the VG UUID. vgrename String VG_new [ COMMON_OPTIONS ] Common options for command: [ -A|--autobackup y|n ] [ -f|--force ] [ --reportformat basic|json ] Common options for lvm: [ -d|--debug ] [ -h|--help ] [ -q|--quiet ] [ -v|--verbose ] [ -y|--yes ] [ -t|--test ] [ --commandprofile String ] [ --config String ] [ --driverloaded y|n ] [ --nolocking ] [ --lockopt String ] [ --longhelp ] [ --profile String ] [ --version ] Use --longhelp to show all options and advanced commands.

    Das muss dann so aussehen!

    vgrename lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A vgubuntu2 ACHTUNG Es kann zu Datenverlust kommen, also wie immer, Hirn einschalten!

    Ich weiß, das die erste eingebaute Platte mit der Nummer /dev/nvme0n1 geführt wird. Die zweite, heute verbaute, hört dann auf den Namen /dev/nvme1n1. Die darf ich nicht anpacken, weil sonst das System nicht mehr startet.

    /etc/fstab

    # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/vgubuntu-root / ext4 errors=remount-ro 0 1 # /boot was on /dev/nvme1n1p2 during installation UUID=178c7e51-a1d7-4ead-bbdf-a956eb7b754f /boot ext4 defaults 0 2 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=7416-4553 /boot/efi vfat umask=0077 0 1 /dev/mapper/vgubuntu-swap_1 none swap sw 0 0

    Jo, wenn jetzt die Partition /dev/mapper/vgubuntu2-root / anstatt /dev/mapper/vgubuntu-root / heißt läuft nichts mehr. Nur um das zu verdeutlichen, auch das könnte man problemlos reparieren. Aber, ich möchte nur warnen!!

    Nachdem die Änderung durchgeführt wurde, habe ich den Rechner neugestartet. Puuh, Glück gehabt, richtige NVMe SSD erwischt 🙂

    Festplatte /dev/mapper/vgubuntu2-root: 463,58 GiB, 497754832896 Bytes, 972177408 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes

    Nun können wir die Platte ganz normal, wie oben beschrieben, mounten. Nun kann ich noch ein paar Dinge kopieren 😉

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

    Restic
    2
    0 Stimmen
    2 Beiträge
    601 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 😉