Borgbackup2 auf Debian 12 in der Hetzner Cloud einrichten
Dieser Blogbeitrag beschreibt, wie Sie das Backup-Tool Borg Backup auf Hetzner Servern mit Debian Linux 12 installieren und konfigurieren
Dieser Blogbeitrag beschreibt, wie Sie das Backup-Tool Borg Backup auf Hetzner Servern mit Debian Linux 12 installieren und konfigurieren
Dieser Blogpost wurde von einer Maschine aus dem Englischen übersetzt. Die Originalversion finden Sie hier: Howto setup borgbackup2 on Debian12 on Hetzner Cloud Servers
Bitte kontaktieren Sie uns , wenn etwas unklar ist, nicht funktioniert oder wenn Sie Unterstützung benötigen.
Dieser Blogbeitrag beschreibt, wie Sie Borgbackup2 auf Debian Linux 12 mit dem deutschen IaaS-Anbieter hetzner.com/cloud/ einrichten. Er ist darauf ausgelegt, ein funktionierendes Borgbackup-System auf bis zu 50-100 Servern einzurichten, abhängig von der Internetverbindung Ihrer Workstation.
Dieser Beitrag lässt eine Vielzahl wichtiger Schlüsselaspekte bei der Einrichtung einer Produktions-Backup-Umgebung aus, wie automatische Sicherheitsupdates, Firewalls, Server-zu-Server-VPN-Verschlüsselung, Intrusion Detection und mehr. Wenn dieses Dokument und Borgbackup Ihr Interesse wecken, ziehen Sie in Betracht, mit einem Blunix GmbH Linux-Experten über die Implementierung von Borg als Backup-Lösung in der Infrastruktur Ihres Unternehmens zu sprechen.
Für diesen Blogbeitrag erstellen wir vier Cloud-Server mit Debian 12:
Der Ressourcenbedarf an RAM und CPU für den Borgbackup2-Server hängt davon ab, wie viele Clients Sie gleichzeitig sichern möchten. Durch die nächtliche Ausführung der Backups zu zufälligen Zeiten zwischen 0 und 6 Uhr morgens können gleichzeitige Backup-Prozesse umgangen werden. Abhängig von der Anzahl der zu sichernden Server ist dies jedoch möglicherweise nicht möglich. Die Aktivierung von Verschlüsselung und Komprimierung erhöht ebenfalls den Ressourcenverbrauch. Offensichtlich ist auch die Menge der pro Server zu synchronisierenden Daten relevant, oder besser gesagt, die Menge der seit dem letzten Backup geänderten Daten.
Als Faustregel können Sie mit vier CPUs und 8 GB RAM für bis zu 15-20 Server mit Festplatten von etwa 200 GB pro Server und nicht zu regelmäßigen Änderungen wie Webservern und Datenbanken, die PHP, Typo3, Wordpress, Blogs und aus Speicherplatzperspektive eher statische Daten hosten, beginnen.
Stellen Sie sicher, dass Sie Ihren öffentlichen SSH-Schlüssel hinzufügen, um sich ohne Passwort per SSH auf den neuen Cloud-Servern anmelden zu können. Im Blunix-Handbuch finden Sie eine Anleitung zum Erstellen eines sicheren privaten und öffentlichen Schlüsselpaars.
Wir erstellen vier Server nach dem Blunix-Namensschema für Server :
| Servername | Hauptfunktion |
|---|---|
| blu-util-prod-backup-1 | Führt die Borgbackup2-Serverkomponente aus |
| blu-util-prod-git-1 | Führt GitLab aus, um den Blunix-Code zu hosten |
| blu-www-prod-web-1 | Führt einen Nginx-Webserver und PHP aus, um eine Website zu hosten |
| blu-www-prod-db-1 | Führt MariaDB für die Webanwendung aus |
Schließlich müssen wir ein Speichervolume für (mindestens) unseren Borgbackup2-Server erstellen, um die Backups der anderen Server zu speichern:
Nachdem alle Server neu erstellt wurden, ist es Zeit für eine erste Anmeldeüberprüfung. Sammeln wir zunächst die IPs der neuen Server.
Um nicht mit IP-Adressen umgehen zu müssen, können wir einige /etc/hosts-Einträge einrichten:
echo "49.13.155.189 blu-util-prod-backup-1 backup
5.75.149.214 blu-www-prod-db-1 db
128.140.37.109 blu-util-prod-git-1 git
188.34.205.212 blu-www-prod-web-1 web" | sudo tee -a /etc/hosts
[sudo] password for user:
49.13.155.189 blu-util-prod-backup-1 backup
5.75.149.214 blu-www-prod-db-1 db
128.140.37.109 blu-util-prod-git-1 git
188.34.205.212 blu-www-prod-web-1 web
ping -c 1 backup
PING blu-util-prod-backup-1 (49.13.155.189) 56(84) bytes of data.
64 bytes from blu-util-prod-backup-1 (49.13.155.189): icmp_seq=1 ttl=52 time=92.8 ms
Um die Interaktion mit allen Servern schnell zu automatisieren, verwenden wir ein kleines Tool namens parallel-ssh. Es benötigt eine einfache Konfigurationsdatei mit einem Hostnamen pro Zeile:
echo "blu-util-prod-backup-1
blu-util-prod-git-1
blu-www-prod-web-1
blu-www-prod-db-1" > hetzner-servers.txt
Wir können diese Liste nun mit parallel-ssh verwenden, um Befehle auf allen Hosts gleichzeitig auszuführen. Um zu prüfen, ob alle Server erreichbar sind und ihre SSH-Host-Keys gleichzeitig zu akzeptieren, verwenden Sie den folgenden Befehl:
sudo apt install pssh
parallel-ssh --hosts=hetzner-servers.txt --user=root --inline --extra-arg="-o StrictHostKeyChecking=accept-new" whoami
[1] 05:35:14 [SUCCESS] blu-util-prod-git-1
root
[2] 05:35:14 [SUCCESS] blu-util-prod-backup-1
root
[3] 05:35:14 [SUCCESS] blu-www-prod-db-1
root
[4] 05:35:14 [SUCCESS] blu-www-prod-web-1
root
In einem realen Szenario würden wir nun die Blunix-Tools verwenden, um initiale Basis-Pakete und Konfigurationen einzurichten, wie im Blunix Manual im Provisioning-Abschnitt dokumentiert. Danach würden wir eine Baseline von Services wie eine Firewall , ein Mailrelay , ein Server-zu-Server-Mesh-VPN und mehr einrichten.
Der Einfachheit halber überspringen wir diese Schritte in diesem Blogbeitrag und konzentrieren uns auf das Einrichten von (Mockups der) Services, die den Hauptzweck der Maschinen darstellen sollen: einen Webserver, einen Datenbankserver und einen GitLab-Server.
Befehle für ssh mit dem &&-Operator verketten, der den nächsten Befehl nur ausführt, wenn der vorherige erfolgreich war (Exit-Status = 0):
ssh root@db "apt-get update && apt-get -y install mariadb-server"
ssh root@web "apt-get update && apt-get -y install nginx"
Installieren wir schnell Gitlab auf dem neuen Git-Server in “einer Zeile” BASH. Sie können mehrzeilige aufeinanderfolgende Befehle definieren, die auf einem entfernten Server direkt auf Ihrer Workstation ausgeführt werden sollen, ohne eine interaktive Shell auf dem Server zu öffnen, indem Sie nach ssh root@server ein doppeltes Anführungszeichen wie folgt verwenden:
ssh root@git "
apt-get update
apt-get install -y curl openssh-server ca-certificates perl
apt-get install -y postfix
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | bash
EXTERNAL_URL='https://git.blunix.com' apt-get -y install gitlab-ce
gitlab-ctl reconfigure
gitlab-ctl restart"
Nachdem alle Server mit ihrer beispielhaften Hauptzweck-Software installiert sind, können wir mit der Installation, Einrichtung und Konfiguration von Borgbackup2 fortfahren, um diese Client-Server zu sichern.
Konfigurieren wir den Borgbackup2-Server. Melden Sie sich zunächst per SSH auf dem Backup-Server an:
ssh root@backup
Richten Sie alle Clients in der /etc/hosts-Datei des Borgbackup-Servers ein:
echo "5.75.149.214 blu-www-prod-db-1
128.140.37.109 blu-util-prod-git-1
188.34.205.212 blu-www-prod-web-1" | tee --append /etc/hosts
Da der erste Eintrag in /etc/hosts, der mit dem Hostnamen des Backup-Servers übereinstimmt, standardmäßig von Debian auf 127.0.1.1 gesetzt wird, kann der Eintrag für den Backup-Server selbst weggelassen werden.
Um die zusätzliche Festplatte unter /home/borgbackup zu mounten, müssen wir zuerst den von Hetzner standardmäßig konfigurierten Mountpoint aushängen:
umount /mnt/HC_Volume*
sed -i 's/.*HC_Volume.*//g' /etc/fstab
Fügen Sie dann die UUID der Festplatte zu /etc/fstab hinzu:
grep -q borg /etc/fstab || echo "UUID=$( blkid -s UUID -o value /dev/sdb) /home/borgbackup ext4 defaults 0 0" >> /etc/fstab
systemctl daemon-reload
Mounten Sie die Festplatte unter /home/borgbackup:
mkdir /home/borgbackup
chmod -v 750 /home/borgbackup
mount -a
Installieren Sie dann die erforderlichen apt-Pakete:
apt update
apt install borgbackup2
Fügen Sie eine Borgbackup-Linux-Gruppe und einen Linux-Benutzer hinzu, um den Backup-Serverprozess ohne Root-Rechte auszuführen. Da das Home-Verzeichnis bereits existiert und ein gemountetes Verzeichnis ist, müssen wir die Dateien aus /etc/skel manuell kopieren und dann den Besitzer des Home-Verzeichnisses des neuen Benutzers ändern:
groupadd --system borgbackup
useradd --system --shell /bin/bash --home-dir /home/borgbackup --create-home --gid borgbackup borgbackup
cp -a /etc/skel/. /home/borgbackup/
chown -R borgbackup:borgbackup /home/borgbackup/
Erstellen Sie die BASH-Liste der Clients und durchlaufen Sie dann die Liste, erstellen Sie für jeden Client ein Archivverzeichnis und initialisieren Sie dann das Archiv. Der Einfachheit halber überspringen wir vorerst die Verschlüsselung der Archivdateien, was bedeutet, dass die Backups der Backup-Client-Server unverschlüsselt auf dem Backup-Server gespeichert werden. Bitte verwenden Sie dies nicht in der Produktion.
Wenn Sie eine fertige Hosting-Umgebung suchen, die FOSS ist und für Ihre Entwickler einfach zu bedienen ist, werfen Sie einen Blick auf Blunix Managed Hosting , das mit einer für den Produktionseinsatz konfigurierten Borgbackup-Lösung geliefert wird.
Für diejenigen, die bereits Borgbackup Version 1 kennen: Der Befehl borg init wurde in borg rcreate (repo create) in Borg Version 2 umbenannt.
clients=(blu-util-prod-backup-1 blu-util-prod-git-1 blu-www-prod-web-1 blu-util-prod-db-1)
for client in ${clients[@]};
do
mkdir -p /home/borgbackup/archives/$client
chown -v borgbackup:borgbackup /home/borgbackup/archives/$client
chmod -v 700 /home/borgbackup/archives/$client
borg2 rcreate --encryption none --repo /home/borgbackup/archives/$client
done
Ändern Sie zusätzlich den Besitz von /home/borgbackup auf den Linux-Benutzer und die Gruppe borgbackup:
chown -R borgbackup:borgbackup /home/borgbackup
Sehen wir uns die im Archivverzeichnis erstellten borgbackup2-Konfigurationsdateien an:
ls /home/borgbackup/archives/*
/home/borgbackup/archives/blu-util-prod-backup-1:
config data hints.1 index.1 integrity.1 README
/home/borgbackup/archives/blu-util-prod-git-1:
config data hints.1 index.1 integrity.1 README
/home/borgbackup/archives/blu-www-prod-db-1:
config data hints.1 index.1 integrity.1 README
/home/borgbackup/archives/blu-www-prod-web-1:
config data hints.1 index.1 integrity.1 README
Eine grundlegende Verzeichnisstruktur für Protokolle und später für öffentliche SSH-Schlüssel von den Backup-Client-Servern ist erforderlich:
mkdir -p /home/borgbackup/logs/prune/
chmod -v 700 /home/borgbackup/logs/prune/
mkdir -v /home/borgbackup/.ssh/
touch /home/borgbackup/.ssh/authorized_keys
chmod 700 /home/borgbackup/.ssh/
chmod 600 /home/borgbackup/.ssh/*
chown -R -v borgbackup:borgbackup /home/borgbackup/
Nachdem der Borgbackup2-Server eingerichtet ist, konzentrieren wir uns auf die Backup-Clients.
Da die Konfiguration der Borgbackup-Clients für alle Server (nahezu) identisch ist, ist dies eine weitere Aufgabe, die wir teilweise mit parallel-ssh automatisieren können. Zuerst müssen wir einen /etc/hosts-Eintrag für den Backup-Server auf allen Backup-Client-Servern einrichten:
parallel-ssh --hosts=hetzner-servers.txt --user=root --inline "echo 49.13.155.189 blu-util-prod-backup-1 | tee -a /etc/hosts"
[1] 18:55:43 [SUCCESS] 49.13.155.189
49.13.155.189 blu-util-prod-backup-1
[2] 18:55:43 [SUCCESS] 188.34.205.212
49.13.155.189 blu-util-prod-backup-1
[3] 18:55:43 [SUCCESS] 5.75.149.214
49.13.155.189 blu-util-prod-backup-1
[4] 18:55:43 [SUCCESS] 128.140.37.109
49.13.155.189 blu-util-prod-backup-1
Als Nächstes installieren Sie die apt-Pakete borgbackup2 und python3-llfuse:
parallel-ssh --hosts=hetzner-servers.txt --user=root --inline "apt-get update && apt-get -y install borgbackup2 python3-llfuse"
Erstellen Sie auf jedem Client-Server ein SSH-Schlüsselpaar. Wir werden diesen Schlüssel später verwenden, um uns auf dem Borgbackup-Server anzumelden und Backups abzulegen.
parallel-ssh --hosts=hetzner-servers.txt --user=root --inline "
chmod 700 /root/.ssh/
test -f /root/.ssh/id_ed25519.pub || ssh-keygen -q -t ed25519 -a 100 -o -f /root/.ssh/id_ed25519 -N ''
chmod 600 /root/.ssh/*
cat /root/.ssh/id_ed25519.pub"
# Erwartete Ausgabe
[1] 21:00:01 [SUCCESS] 49.13.155.189
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPe8a1IUf6qv5yqjqiPm9X+7ATm/uVTceS3PGkgGnInN root@blu-util-prod-backup-1
[2] 21:00:01 [SUCCESS] 188.34.205.212
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIoLelk1eP5XoCP6WAD7hRHSdePEm5XsEpjUsRACUsFX root@blu-www-prod-web-1
[3] 21:00:01 [SUCCESS] 5.75.149.214
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOt0hyyxw0UCjQsUJ1+y0kP5HOcIymKWLD2gDqrR7yTJ root@blu-www-prod-db-1
[4] 21:00:01 [SUCCESS] 128.140.37.109
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIzUXL4IBxsK5bnbQ0sPyBunsD0k5RkEBE1PmCy8wBru root@blu-util-prod-git-1
Alle Backup-Client-Server müssen den SSH-Host-Schlüssel des Backup-Servers akzeptieren, um SSH-Verbindungen automatisch / in Skripten herstellen zu können:
parallel-ssh --hosts=hetzner-servers.txt --user=root --inline "ssh-keyscan -H blu-util-prod-backup-1 | tee -a /root/.ssh/known_hosts"
Der Befehl borg2 erfordert, dass die Umgebungsvariable BORG_REPO gesetzt ist. Diese Variable wird verwendet, um borg2 mitzuteilen, als welcher Linux-Benutzer und auf welchem Server es sich per SSH anmelden muss und unter welchem Pfad es seine Backup-Archive ablegen darf. Der folgende Befehl speichert die Variable BORG_REPO in der Datei /root/.bashrc aller Backup-Client-Server, sodass sie bei jeder Anmeldung per SSH auf dem Backup-Client-Server geladen wird. Auf diese Weise können Sie direkt auf dem Backup-Client-Server mit Backups interagieren, diese debuggen und wiederherstellen, was die beabsichtigte Verwendung von Borgbackup ist.
parallel-ssh --hosts=hetzner-servers.txt --user=root --inline 'echo export BORG_REPO="ssh://borgbackup@blu-util-prod-backup-1/home/borgbackup/archives/$(hostname)" | tee -a /root/.bashrc'
Nachdem Sie die Variable in Ihre /root/.bashrc-Datei geschrieben haben, melden Sie sich einfach ab, damit sie geladen wird:
echo $BORG_REPO # Gibt keine Ausgabe
exit
Und melden Sie sich erneut an:
ssh root@web
Die Variable sollte nun aus Ihrer /root/.bashrc-Datei exportiert werden:
echo $BORG_REPO
ssh://borgbackup@blu-util-prod-backup-1/home/borgbackup/archives/blu-www-prod-web-1
Der eigentliche Befehl zum Erstellen eines Backups wird in einem BASH-Skript gespeichert, das später über einen Cronjob ausgeführt werden kann. Hier ist ein funktionierendes Beispiel für ein Borg-Create-Shell-Skript für Debian Linux 12. Das folgende Skript sichert alles in Ihrem Dateisystembaum, einschließlich gemounteter Dateisysteme. Blunix empfiehlt, immer alles zu sichern, einschließlich der gesamten Dateien des Debian-Linux-Betriebssystems, denn man weiß nie, wann man sie brauchen könnte, und Backup-Speicherplatz ist im Allgemeinen günstig, insbesondere jetzt, da Sie Deduplizierung und Komprimierung mit Borg-Backup verwenden :)
Speichern wir zuerst das Skript auf der Workstation und laden es dann auf alle Backup-Client-Server hoch:
cat > borg2-create.sh << 'EOF'
#!/bin/bash
#
# Create a borg2 backup of this server
source /root/.bashrc.d/borgbackup.sh
current_date=$(date +%d_%m_%y-%H_%M_%S)
logfile=/var/log/borgbackup/${current_date}.log
echo -e "BACKUP STARTING AT $(date +%d_%m_%y-%H_%M_%S)\n\n" >> $logfile
# Run hook scripts here and save the data in the filesystem of the backup client server
# The borg backup will later backup (almost) all files on the server
# mysqldump > $logfile 2>&1
# gitlab-backup create > $logfile 2>&1
# Create the actual backup. Extend the --exclude arguments as required in your usecase.
borg create \
--verbose \
--stats \
--exclude-caches \
--exclude /mnt \
--exclude /media \
--exclude /tmp \
--exclude /proc \
--exclude /sys \
--exclude /run \
--exclude /var/lib \
--exclude /var/log/lastlog \
--exclude /home/borgbackup/archives \
--exclude "*.journal" \
--exclude "*.fsck" \
--exclude "*.lost+found" \
$current_date / >> $logfile 2>&1
EOF
Laden Sie nun das Borg-Backup-Skript auf die Server:
parallel-scp --hosts=hetzner-servers.txt --user=root borg2-create.sh /usr/local/sbin/borg2-create.sh
parallel-ssh --hosts=hetzner-servers.txt --user=root --inline 'chown -v root:root /usr/local/sbin/borg2-create.sh && chmod -v 500 /usr/local/sbin/borg2-create.sh'
rm borg2-create.sh
Um die Erstellung nächtlicher Backups zu automatisieren, richten wir einen Cronjob ein, der das BASH-Skript /usr/local/sbin/borg2-create.sh zu einer zufälligen Minute einer zufälligen Stunde zwischen 0 und 6 Uhr morgens ausführt:
parallel-ssh --hosts=hetzner-servers.txt --user=root --inline 'grep --no-messages borg2-create.sh /var/spool/cron/crontabs/root || (crontab -l 2>/dev/null; echo "$((0 + RANDOM % 59)) $((0 + RANDOM % 6)) * * * /usr/local/sbin/borg2-create.sh") | crontab -'
Um die neu erstellten Crontab-Einträge anzuzeigen:
parallel-ssh --hosts=hetzner-servers.txt --user=root --inline "crontab -l"
[1] 01:42:41 [SUCCESS] 49.13.155.189
11 1 * * * /usr/local/sbin/borg2-create.sh
[2] 01:42:41 [SUCCESS] 188.34.205.212
56 5 * * * /usr/local/sbin/borg2-create.sh
[3] 01:42:41 [SUCCESS] 5.75.149.214
18 2 * * * /usr/local/sbin/borg2-create.sh
[4] 01:42:41 [SUCCESS] 128.140.37.109
16 2 * * * /usr/local/sbin/borg2-create.sh
Borgbackup verwendet die passwortlose SSH-Schlüsselpaar-Authentifizierung, um Daten zwischen Clients und Servern zu senden.
Die öffentlichen SSH-Schlüssel aller Backup-Client-Server für den Root-Benutzer müssen für den Borgbackup-Benutzer auf dem Backup-Server installiert werden. Dies liegt daran, dass nur der Root-Benutzer alle Dateien im Dateisystem des Backup-Clients lesen kann.
Dieser Befehl erstellt die ~/.ssh/-Verzeichnisstruktur auf dem Backup-Server:
ssh root@backup "mkdir -v /home/borgbackup/.ssh/ && touch /home/borgbackup/.ssh/authorized_keys && chmod -v 700 /home/borgbackup/.ssh/ && chmod 600 /home/borgbackup/.ssh/*"
Laden Sie alle öffentlichen SSH-Schlüssel der Backup-Clients in eine BASH-Variable:
all_ssh_public_keys=$(parallel-ssh --hosts=hetzner-servers.txt --user=root --inline 'cat /root/.ssh/id_ed25519.pub' | grep ^ssh)
echo "$all_ssh_public_keys"
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPe8a1IUf6qv5yqjqiPm9X+7ATm/uVTceS3PGkgGnInN root@blu-util-prod-backup-1
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIoLelk1eP5XoCP6WAD7hRHSdePEm5XsEpjUsRACUsFX root@blu-www-prod-web-1
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIzUXL4IBxsK5bnbQ0sPyBunsD0k5RkEBE1PmCy8wBru root@blu-util-prod-git-1
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOt0hyyxw0UCjQsUJ1+y0kP5HOcIymKWLD2gDqrR7yTJ root@blu-www-prod-db-1
Fügen Sie als Nächstes alle öffentlichen SSH-Schlüssel in eine Datei ein, die wir auf den Backup-Server hochladen können. Wir beschränken jeden Backup-Client darauf, nur den Befehl borg2 serve ausführen zu können:
touch backup-authorized-keys.txt
clients=(blu-util-prod-backup-1 blu-util-prod-git-1 blu-www-prod-web-1 blu-www-prod-db-1)
for client in ${clients[@]};
do
echo "command=\"/usr/bin/borg2 serve --append-only --restrict-to-path /home/borgbackup/archives/$client\",restrict $(grep $client <<< $all_ssh_public_keys)" >> backup-authorized-keys.txt
done
Laden Sie dann die Datei authorized_keys auf den Backup-Server:
scp backup-authorized-keys.txt root@backup:/home/borgbackup/.ssh/authorized_keys
ssh root@backup "chown -R borgbackup:borgbackup /home/borgbackup/.ssh/ && chmod 600 /home/borgbackup/.ssh/authorized_keys"
rm backup-authorized-keys.txt
Um die Datei /home/borgbackup/.ssh/authorized_keys anzuzeigen:
ssh root@backup "cat /home/borgbackup/.ssh/authorized_keys"
command="/usr/bin/borg2 serve --append-only --restrict-to-path /home/borgbackup/archives/blu-util-prod-backup-1",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMvOS1zheS9gYLKDYBdSH0ugwqXx1z0FfvCB+nIDtan5 root@blu-util-prod-backup-1
command="/usr/bin/borg2 serve --append-only --restrict-to-path /home/borgbackup/archives/blu-util-prod-git-1",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJVzduwcbuNDtPRKpvssns+c0KcSPUcq0DXsmmUN+Uat root@blu-util-prod-git-1
command="/usr/bin/borg2 serve --append-only --restrict-to-path /home/borgbackup/archives/blu-www-prod-web-1",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMt42AcSgMQOV99CMMlQ9LMjQSUkVHDarvFGTsoUQf/z root@blu-www-prod-web-1
command="/usr/bin/borg2 serve --append-only --restrict-to-path /home/borgbackup/archives/blu-www-prod-db-1",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGJyJCeH7mh6vMiwM8CiuFlVgKzZZbRW4L0Dg7iO2va7 root@blu-www-prod-db-1
Zeit, das neue Backup-System zu testen. Melden Sie sich bei einem beliebigen Client-Server an:
ssh root@web
Führen Sie nun die folgenden Befehle aus, um ein erstes kleines Backup des Verzeichnisses /root/ zu erstellen:
borg2 create first-backup /root/
Warning: Attempting to access a previously unknown unencrypted repository!
Do you want to continue? [yN] y
Um alle auf dem Backup-Server vorhandenen Backups aufzulisten:
borg2 rlist
first-backup Sun, 2024-02-11 22:52:22 +0000 [6211ee61c6515848ca3f70655b86c26dfb9998bb88dface986edff969a4ceb3f]
Um den Inhalt eines bestimmten Backups aufzulisten:
borg2 list first-backup
drwx------ root root 0 Sun, 2024-02-11 21:28:39 +0000 root
-rw-r--r-- root root 679 Sun, 2024-02-11 20:15:49 +0000 root/.bashrc
drwx------ root root 0 Sun, 2024-02-11 20:03:25 +0000 root/.ssh
-rw------- root root 81 Sun, 2024-02-11 12:58:38 +0000 root/.ssh/authorized_keys
[...]
Um den Inhalt eines Verzeichnisses innerhalb eines bestimmten Backups aufzulisten:
borg2 list first-backup root/.ssh
drwx------ root root 0 Sun, 2024-02-11 20:03:25 +0000 root/.ssh
-rw------- root root 81 Sun, 2024-02-11 12:58:38 +0000 root/.ssh/authorized_keys
-rw------- root root 419 Sun, 2024-02-11 19:57:53 +0000 root/.ssh/id_ed25519
-rw------- root root 105 Sun, 2024-02-11 19:57:53 +0000 root/.ssh/id_ed25519.pub
-rw-r--r-- root root 978 Sun, 2024-02-11 20:03:25 +0000 root/.ssh/known_hosts
Die benutzerfreundlichste Methode zur Wiederherstellung von Dateien besteht darin, alle Backups direkt auf dem Backup-Client-Rechner zu mounten:
borg2 mount /mnt/
ls /mnt
first-backup
ls /mnt/first-backup/root/.ssh/
authorized_keys id_ed25519 id_ed25519.pub known_hosts
Vergessen Sie nach der Wiederherstellung nicht, die Backup-Archive wieder auszuhängen:
umount /mnt/
Um mehr über gängige Anwendungsfälle und fortgeschrittenere Verwendung von Borg zum Erstellen, Wiederherstellen, Debuggen und Interagieren mit Backup-Archiven zu erfahren, lesen Sie bitte den Abschnitt im Blunix Manual über Borgbackup .
Suchen Sie
Linux Notfallunterstützung,
Linux-Beratung für Projekte,
Linux Managed Hosting,
Qubes OS Beratung und Support oder
Online- und Vor-Ort-Schulungen?