Skip to content

Forgejo Installation mit Restic nach Hetzner S3 sichern

Restic
2 1 260
  • Ich sichere schon jahrelang alle meine Daten mit Restic, gerne auch ins Internet oder neumodisch Cloud genannt. Besser ausgedrückt, auf die Rechner anderer Menschen.

    Warum ist das wichtig?

    Die könnten mitlesen, was da liegt. Also verschlüsseln wir das Ganze. Restic macht das mit einer AES256 Verschlüsselung. Im Netz sieht das dann auf einem Object Storage von Hetzner so aus.

    47bc51e4-29ae-4e56-82e7-e0cb30a5be12-image.png

    Ich nehme für jeden Sicherungspunkt ein neues Projekt bei Hetzner, der Grund ist, dass ich nicht in verschiedene Unterordner mit entsprechenden Schlüsseln speichern kann. Zu mindestens hatte ich das mal nicht hinbekommen. Ein Wochenende mit verplempert. OK, also 1 Projekt je Backup-Vorgang. Das könnte man im Falle des Forgejos Servers auch nur mit einem Projekt machen. Warum? Wenn die Schlüssel in die falschen Hände fallen, wären ja beide Schlüssel weg. Ok, dann hätten man aber sowieso ein anderes Problem.

    Aber, alle meine anderen Sicherungen, wären nicht gefährdet.

    Was muss man sichern? Die Grundlage ist mein Forgejo Podman Projekt.

    Ok, fangen wir mal langsam an 😉

    Hetzner S3

    Ihr legt dort bitte zwei Projekte an.

    6cca1074-ad23-4cab-83c6-9ee9d8a6cd46-image.png

    Innerhalb der Projekte legt ihr dann ein Bucket an. Für dieses Projekte legt ihr Zugangsdaten an und notiert die bitte. Die brauchen wir später noch.

    Forgejo Server

    Für die Forgejo Installation muss man zwei Ordner sichern. In meinem Fall

    • /home/forgejo
    • /home/pguser/db-data

    Was brauchen wir dafür?

    • AWS Credentials File
    • Restic Passwörter
    • Restic Backup Script

    Software

    Restic installieren

    apt install restic
    

    AWS Credentials

    Wir legen ein File an

    mkdir /root/.aws
    nano /root/.aws/credentials
    

    Inhalt

    [forgejo]
    aws_default_region="nbg1"
    aws_access_key_id="<ACCESS_KEY>"
    aws_secret_access_key="<SECRET_ACCESS_KEY"
    
    [postgres]
    aws_default_region="nbg1"
    aws_access_key_id="<ACCESS_KEY>"
    aws_secret_access_key="<SECRET_ACCESS_KEY>"
    

    Sollte selbsterklärend sein. Die Keys habt ihr eben aufgeschrieben. Solltet ihr nicht Nürnberg bei Hetzner gewählt haben, müsst ihr die Region entsprechend ändern.

    Restic Passwörter

    Zwei Passwörter anlegen, bitte ordentliche 😉 Hier seht ihr, wo ich die abgelegt habe.

    forgejo_pwd="/root/.forgejo_pwd"
    postgres_pwd="/root/.postgres_pwd"
    

    Restic Backup Script

    Das Script.

    #!/bin/bash
    # Script um mit Restic Daten automatisiert zu sichern!
    # Dient zum Sichern der Forgejo Installation -> Hetzner S3
    
    
    ## S3 Forgejo
    s3_domain="s3:nbg1.your-objectstorage.com"
    s3_folder="forgejo2"
    s3_bucket="forgejo2"
    
    
    ## S3 Postgres
    s3_domain_pg="s3:nbg1.your-objectstorage.com"
    s3_folder_pg="postgres2"
    s3_bucket_pg="postgres2"
    
    
    ## PWD
    forgejo_pwd="/root/.forgejo_pwd"
    postgres_pwd="/root/.postgres_pwd"
    
    
    # Was soll gesichert werden?
    backup_pfad_forgejo="/home/forgejo"
    backup_pfad_postgres="/home/pguser/db-data/dump.txt"
    
       
    # Forgejo Start
    export AWS_PROFILE=forgejo
    #restic -r $s3_domain/$s3_bucket/$s3_folder init > forgejo.log
    #restic --password-file $forgejo_pwd -r $s3_domain/$s3_bucket/$s3_folder ls latest > forgejo.log
    restic --password-file $forgejo_pwd  -r $s3_domain/$s3_bucket/$s3_folder backup $backup_pfad_forgejo > forgejo.log
    restic --password-file $forgejo_pwd -r $s3_domain/$s3_bucket/$s3_folder forget --keep-last 3 --keep-monthly 3 --prune >> forgejo2.log
    # Testen
    restic --password-file $forgejo_pwd -r $s3_domain/$s3_bucket/$s3_folder check --read-data >> forgejo3.log
    
    
    # Postgres Start
    export AWS_PROFILE=postgres
    podman exec -it postgres pg_dump -U postgres -f /var/lib/postgresql/data/dump.txt
    #restic -r $s3_domain_pg/$s3_bucket_pg/$s3_folder_pg init > postgres.log
    restic --password-file $postgres_pwd -r $s3_domain_pg/$s3_bucket_pg/$s3_folder_pg backup $backup_pfad_postgres > postgres.log
    restic --password-file $postgres_pwd -r $s3_domain_pg/$s3_bucket_pg/$s3_folder_pg forget --keep-last 3 --keep-monthly 3 --prune >> postgres2.log
    # Testen
    restic --password-file $postgres_pwd -r $s3_domain_pg/$s3_bucket_pg/$s3_folder_pg check --read-data >> postgres3.log
    

    Damit es funktioniert

    chmod +x   forgejo_backup.sh
    

    Sollte alles selbsterklärend sein.

    Erläuterungen

    Init

    Ein paar Erklärungen. Wenn ihr das Script das erste Mal nutzt kommentiert bitte alle Restic Zeilen aus, bis auf diese.

    restic -r $s3_domain/$s3_bucket/$s3_folder init > forgejo.log
    

    Hiermit wird das Restic Verzeichnis initialisiert, dazu müsst ihr das Restic Passwort eingeben, was ihr weiter oben angelegt habt. Danach braucht ihr diese Zeile nicht mehr. Wieder auskommentieren. Das bitte für Forgejo & Postgres machen.

    ls latest

    Wenn ihr mal testen wollt, ob was im Repo liegt, könnt ihr das mit dieser Zeile machen.

    restic --password-file $forgejo_pwd -r $s3_domain/$s3_bucket/$s3_folder ls latest > forgejo.log
    

    Backup

    Diese Zeile

    restic --password-file $forgejo_pwd  -r $s3_domain/$s3_bucket/$s3_folder backup $backup_pfad_forgejo > forgejo.log
    

    legt das Backup an.

    Forget

    Diese Zeile löscht alle Daten, die dem Filter nicht entsprechen.

    restic --password-file $forgejo_pwd -r $s3_domain/$s3_bucket/$s3_folder forget --keep-last 3 --keep-monthly 3 --prune >> forgejo2.log
    

    Es werden nur Daten behalten, nach einem eingestellten Wert. Sonst hätten man ja irgendwann ganz viele Daten, das möchte ich nicht.

    Testen

    Und diese Zeile testet das Repo

    restic --password-file $forgejo_pwd -r $s3_domain/$s3_bucket/$s3_folder check --read-data >> forgejo3.log
    

    Fertig. In den Logs könnt ihr nachlesen, was passiert ist. Besonders wichtig bei Fehlern.

    Normalerweise checke ich meine Backups noch zusätzlich mit CheckMK, ob diese auch durchgeführt wurden. Das ist aber ein anderes Thema.

    Crontab

    Und wenn alles funktioniert, legt ihr einen crontab an.

    crontab -e
    

    Inhalt

    # m h  dom mon dow   command
    03 09 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" --reloadcmd "systemctl restart nginx.service" > /dev/null
    0 3 * * * /root/forgejo_backup.sh
    

    Fertig!

    Viel Spaß

    Links

    Und danke an Restic, ich liebe diese Software 😉

  • Ich habe ja im obigen Beispiel, den gesamten Ordner von der Postgres Installation gesichert.

    backup_pfad_postgres="/home/pguser/db-data"
    

    Ich habe dann mal ein wenig in der Dokumentation gelesen und das hier gefunden.

    Einfach den Ordner zu sichern, ist ja bei jeder Datenbank ein gewisses Risiko. Die Konsistenz der Daten ist nicht gesichert. Darum gibt es bei den Datenbanken auch immer Tools, mit denen man die Daten sichern kann. In der Doku steht folgendes.

    pg_dump — extract a PostgreSQL database into a script file or other archive file

    Aber wichtiger ist das hier.

    pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently. pg_dump does not block other users accessing the database (readers or writers).

    Das macht also konsistente Backups. Wichtig noch zu wissen ist folgendes.

    pg_dump only dumps a single database. To back up an entire cluster, or to back up global objects that are common to all databases in a cluster (such as roles and tablespaces), use pg_dumpall.

    Ok, das scheint gut geeignet zu sein, um die Datenbank zu sichern. Aber, wie? Auf meinen Eingangsbeitrag kam es zu folgendem Dialog auf Mastodon.

    Das war der Anstoß sich mit dem Thema zu beschäftigen. Und ich hatte dann folgende Lösung.

    podman exec -it postgres pg_dump -U postgres -f /var/lib/postgresql/data/dump.txt
    

    Ok, was mache ich hier? Wir führen einen Befehl vom Host aus gesehen, im Container aus.

    podman exec -it postgres
    

    Der Teil führt den folgenden Befehl im Container aus.

    pg_dump -U postgres -f /var/lib/postgresql/data/dump.txt
    
    • pg_dump - Das Tool fürs Backup
    • -U postgres - Der Befehl wird als User postgres ausgeführt
    • -f /var/lib/postgresql/data/dump.txt - Das Dump File wird im Data Ordner abgelegt, den haben wir ja persistent auf dem Host.

    Somit kann ich das jetzt einfach in mein Backup Script einbauen und brauchen nicht mehr den ganzen Ordner zu kopieren, sondern nur noch das Dump File. Ich werde diese Änderungen in das obige Script einbauen.

  • Restic v0.16.5 released

    Restic restic linux
    1
    0 Stimmen
    1 Beiträge
    152 Aufrufe
    Niemand hat geantwortet
  • Debian Bookworm 12.6 released

    Linux debian linux
    1
    0 Stimmen
    1 Beiträge
    170 Aufrufe
    Niemand hat geantwortet
  • Manjaro Stable jetzt mit Plasma 6

    Linux kde linux wayland plasma6
    1
    0 Stimmen
    1 Beiträge
    292 Aufrufe
    Niemand hat geantwortet
  • Restic v0.16.1 released

    Restic restic linux
    1
    0 Stimmen
    1 Beiträge
    162 Aufrufe
    Niemand hat geantwortet
  • Redis - Zweite Instanz

    Redis redis linux
    1
    0 Stimmen
    1 Beiträge
    295 Aufrufe
    Niemand hat geantwortet
  • Kopia - Administrative Aufgaben

    Kopia kopia linux
    1
    0 Stimmen
    1 Beiträge
    297 Aufrufe
    Niemand hat geantwortet
  • Rest-Server

    Verschoben Restic rest-server linux restic
    8
    0 Stimmen
    8 Beiträge
    723 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.
  • LUKS verschlüsselte Platte mounten

    Linux linux
    2
    1
    0 Stimmen
    2 Beiträge
    1k 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