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.

  • Python - Interessante Packages

    Python3 python linux
    1
    0 Stimmen
    1 Beiträge
    133 Aufrufe
    Niemand hat geantwortet
  • Raspberry Pi5 - First Boot

    RaspberryPi raspberrypi linux debian
    1
    2
    0 Stimmen
    1 Beiträge
    270 Aufrufe
    Niemand hat geantwortet
  • Star64 - UART

    Hardware star64 risc-v linux
    1
    0 Stimmen
    1 Beiträge
    77 Aufrufe
    Niemand hat geantwortet
  • NanoPi5 - eMMC

    Verschoben NanoPi R5S openwrt nanopir5s linux
    1
    4
    0 Stimmen
    1 Beiträge
    250 Aufrufe
    Niemand hat geantwortet
  • ZFS - Wichtige Befehle

    Linux zfs linux
    2
    0 Stimmen
    2 Beiträge
    868 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/
  • Ubuntu Cinnamon Remix 21.04

    Linux ubuntu cinnamon linux
    2
    1
    0 Stimmen
    2 Beiträge
    338 Aufrufe
    FrankMF
    Nach einem kurzen Test denke ich, das für das Projekt noch eine Menge Arbeit wartet. Verschlüsselte Installation Geht nicht, nach Reboot klappt die Passwortabfrage nicht Unverschlüsselte Installation Ok, nachdem ich dann die Zeichensatzprobleme im Griff hatte, warum bekommt man das eigentlich nicht in den Griff?, hatte ich nach der zweiten Installation eine funktionierende Installation. Kurz Fazit Dringend den Installer überarbeiten. Die Ubuntu Installation funktioniert auf dem Rechner problemlos. Der Desktop gefällt mir auf den ersten Blick ganz gut. Kein Wunder, man fühlt sich ja sofort zu Hause Aktuell in meinen Augen produktiv nicht einsetzbar! Und HiDPi habe ich noch gar nicht getestet...
  • ACER und der UEFI-Booteintrag!

    Linux linux
    1
    0 Stimmen
    1 Beiträge
    238 Aufrufe
    Niemand hat geantwortet
  • NodeBB - Update

    NodeBB nodebb linux
    1
    0 Stimmen
    1 Beiträge
    702 Aufrufe
    Niemand hat geantwortet