Wer einen eigenen (Home-)Server betreibt, sollte sich auf jeden Fall Gedanken über Backups machen. Spätestens, wenn wichtige Dateien mal unbeabsichtigt gelöscht wurden, kann man froh sein, wenn man auf Backups zurück greifen kann.
Deshalb möchte ich an dieser Stelle meine Backup-Strategie für Linux-Server vorstellen. Diese basiert hauptsächlich auf dem Programm Borg Backup und wird ergänzt durch eigene Backup-Skripte.
Als Betriebssystem kommt hier Ubuntu Server 18.04 zum Einsatz, das Gezeigte kann allerdings auch auf anderen Distributionen umgesetzt werden.
Die Inspiration zu dieser Tutorial stammt aus einem Artikel von Thomas Leister: Borg Backup für Serversicherungen. Ich habe diese Strategie jedoch an meine Bedürfnisse angepasst.
Genau dies solltet ihr übrigens auch machen: Jeder hat hier individuelle Anforderungen, daher wird es nicht die eine Lösung geben. Daher könnt ihr die hier gezeigte Lösung/Skripte als Vorlage nehmen, die ihr dann an eure eigenen Bedürfnisse anpasst.
Inhalt
Borg Backup
Den größten Teil der Arbeit übernimmt das Programm Borg Backup. Dies ist ein Backup-Programm, welches einige Vorteile bietet:
- Kompression: Die Backups werden komprimiert.
- Verschlüsselung: Die Backups können verschlüsselt werden.
- Deduplizierung: Bei mehreren aufeinander folgenden Backups werden nur die inkrementellen Änderungen gesichert. Wenn mit dem ersten Backup beispielsweise 1 GB Daten gespeichert wurden und es ändern sich darauf hin nur 100 MB, dann werden im folgenden Backup nur diese 100 MB an Daten gesichert.
Durch die Verschlüsselung ist die Sicherheit der Backups gewährleistet, so dass man diese auch z.B. auf einem FTP-Server im Internet sichern könnte.
Durch die Verschlüsselung und Deduplizierung sind die Backups recht kompakt und werden schnell angefertigt.
Um Borg Backup zu installieren, bringen wir das System erst einmal auf den aktuellen Stand:
apt update && apt upgrade -V && apt dist-upgrade && apt autoremove
Anschließend kann Borg Backup installiert werden:
apt install borgbackup
Nun kann es schon an die Einrichtung des Backups gehen.
Backup einrichten
Übersicht
Zunächst ein paar Worte zum grundsätzlichen Vorgehen.
Ziel ist ein Backup-Skript, welches alle wichtigen Teile des Systems sichert:
- Wichtige Dateien und Verzeichnisse.
- Komplette Anwendungen.
Unter kompletten Anwendungen verstehe ich hier ein komplettes Backup einer Anwendung, welches grundsätzlich auch erst mal für sich allein angefertigt werden kann. Als Beispiel für eine solche Anwendung dient im Rahmen dieses Artikels Nextcloud, eine selbst gehostete Cloud-Lösung. Wie ein Backup von Nextcloud angefertigt werden kann, habe ich bereits im Artikel Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript beschrieben. Das Skript, welches im Rahmen dieses Artikels erstellt wurde, kann nun für das komplette Backup des Servers wiederverwendet werden.
Jedoch kann auch jede beliebige andere Anwendung mittels des Server-Backup-Skripts gesichert werden: Weitere Beispiele wären hier z.B. FHEM, oder auch ein Firefox Sync-Server.
Das grundsätzliche Vorgehen sieht nun so aus, dass zunächst alle zu sichernden Anwendungen einzeln auf einen temporären Speicherort gesichert werden. Anschließend werden diese einzelnen Backups zusammen mit den zu sichernden Verzeichnissen des Systems an Borg Backup für die Gesamt-Sicherung übergeben. Anschließend werden die temporären Backups der Anwendungen wieder gelöscht.
In diesem Zusammenhang ist es nur wichtig, dass keine Teile des Systems doppelt gesichert werden. Wenn z.B. das Web-Verzeichnis (meist unter /var/www zu finden) gesichert werden soll, ist bei der Übergabe an Borg Backup das Nextcloud-Verzeichnis (unter /var/www/nextcloud) vom Backup auszuschließen, da dies ja schon durch die Nextcloud-Sicherung gespeichert wurde.
Individuelle Sicherung von Anwendungen
Zunächst beschäftigen wir uns mit dem Backup einzelner Anwendungen. Wie bereits erwähnt, dient hier Nextcloud als Beispiel-Anwendung, die es nun zu sichern gilt. Dieses Thema wurde hier bereits im Blog mit dem Artikel Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript behandelt. Aus diesem Grund sei hier auf das dazugehörige Bash-Skript verwiesen, welches auf Codeberg verfügbar ist: Nextcloud Backup Restore
Wenn andere Anwendungen gesichert werden sollen, empfiehlt es sich, hier ebenfalls ein gesondertes Skript anzufertigen. Als weiteres Beispiel sei an dieser Stelle WordPress erwähnt (WordPress: Backups erstellen und wiederherstellen – manuell oder per Skript). Das dazugehörige Bash-Skript ist ebenfalls auf Codeberg verfügbar: WordPress Backup Restore
Borg Repository einrichten
Vor der Erstellung des Backup-Skripts muss noch das sog. Borg-Repository angelegt werden. In diesem Beispiel erfolgt dies auf einer zweiten internen HDD (/media/hdd2). Es kann aber auch ein beliebiges anderes Verzeichnis sein (z.B. ein per fstab gemountetes NAS). Das Repository wird dabei mit folgenden Befehlen angelegt:
mkdir -p /media/hdd2/server_backup/borg borg init -e repokey-blake2 /media/hdd2/server_backup/borg
Beim Angelgen wird nach einem Passwort gefragt. Dieses sollte ein ausreichend sicheres Passwort sein. Dieses Passwort sollte man sich auch gut merken, denn ohne das Passwort kann kein Zugriff auf die Backups erfolgen. Am besten speichert es man sich gleich in einem Passwort-Safe (wie z.B. KeePass ab).
Der Befehl zum Initialisieren eines Repositories bietet noch weitere Optionen. So ist es auch möglich, die Verschlüsselung mittels einer Schlüssel-Datei zu realisieren. Eine genaue Beschreibung zum Initialisieren von Borg-Repositories ist in der offiziellen Dokumentation zu finden.
Auch wenn es möglich ist, ein Repository ohne Verschlüsselung anzulegen, rate ich davon ab. Die Verschlüsselung sollte beim Initialisieren immer verwendet werden.
Backup-Skript erstellen
Wie sämtliche Skripte speichere ich auch die Backup-Skripte im Verzeichnis /home/<user>/scripts. Hier wird erst einmal das Skript selbst erstellt:
nano /home/user/scripts/server_backup.sh
Der Inhalt sieht dann wie folgt aus:
#!/bin/bash
#
# Backup Script for Linux servers
#
# This script needs to be customized to fit your needs. Most important are the folder and applications which should be part of the backup.
# The folders to backup are specified in the variable $borgBackupDirs (see below)
# Besides these folders, Nextcloud (https://nextcloud.com/) is taken as example for an additional web application which should be included in the backup.
#
# Required software and scripts:
# - Borg Backup (https://www.borgbackup.org/)
# - When Nextcloud backup should be included: Nextcloud Backup/Restore scrips (https://codeberg.org/DecaTec/Nextcloud-Backup-Restore)
#
# Remarks
# - The borg repository has to be set up before the script is called.
#
# IMPORTANT
# You have to customize this script (directories, users, etc.) for your actual environment.
# All entries which need to be customized are tagged with "TODO".
#
#
# Calling via cron:
# - crontab -e: Every night at 02:05
# m h dom mon dow command
# 5 2 * * * /home/user/scripts/server_backup.sh > /dev/null 2>&1
#
#
# Environment variables
#
# TODO: The borg repository's password
export BORG_PASSPHRASE='passw0rd'
# This has to be set when the repository has been created by user and the script is called by cron
export BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK=yes
# For "Warning: The repository at location ... was previously located at ..."
export BORG_RELOCATED_REPO_ACCESS_IS_OK=yes
#
# Variables
#
startTime=$(date +%s)
currentDate=$(date --date @"$startTime" +"%Y%m%d_%H%M%S")
currentDateReadable=$(date --date @"$startTime" +"%d.%m.%Y - %H:%M:%S")
# TODO: Customize according to your needs
logDirectory="/home/user/backup_logs/server_backup"
logFile="${logDirectory}/server-backup-${currentDate}.log"
# TODO: This is the local backup dir where the local backups (e.g. Nextcloud) are stored before being backuped by borg backup.
localBackupDir="/media/hdd1/backups_local_temp"
# TODO: Mount point of the backup destination folder
backupDiskMount="/media/hdd2"
# TODO: This is the dir where the borg respository is stored
borgRepository="${backupDiskMount}/server_backup/borg"
# TODO: List of (local) dirs borg should backup
borgBackupDirs="/var/www/ /etc/ /home/user/ /media/hdd1/NetworkShares/ $localBackupDir/"
# Nextcloud
localNextcloudBackupDir="${localBackupDir}/nextcloud"
# TODO: To be excluded by borg (the Nextcloud web directory)
nextcloudDirBorgExclude="/var/www/nextcloud"
#
# Create log dir if it does not exist already
#
if [ ! -d "${logDirectory}" ]
then
mkdir -p "${logDirectory}"
fi
# Function for error messages
errorecho() { cat <<< "$@" 1>&2; }
#
# Write output to logfile. Comment following lines in order to see output on terminal.
#
exec > >(tee -i "${logFile}")
exec 2>&1
#
# Preparation
#
# Check for root
if [ "$(id -u)" != "0" ]
then
errorecho "ERROR: This script has to be run as root!"
exit 1
fi
#
# Check if directories already exist
#
# Local backup directory
if [ ! -d "${localBackupDir}" ]
then
mkdir -p "${localBackupDir}"
fi
# Nextcloud
if [ ! -d "${localNextcloudBackupDir}" ]
then
mkdir -p "${localNextcloudBackupDir}"
fi
echo -e "\n###### Starting server backup on ${currentDateReadable} ######\n"
#
# Create a list with installed software
#
echo -e "\n######"
echo -e "\nCreate a list with installed software"
dpkg --get-selections > "${localBackupDir}/software.list"
echo -e "\nDone\n"
echo -e "######\n"
#
# Backup Nextcloud
#
# TODO: Storage location of the script
echo -e "\n######"
echo -e "\nBackup Nextcloud"
/bin/bash /home/user/scripts/NextcloudBackup.sh ${localNextcloudBackupDir}
echo -e "\nDone\n"
echo -e "######\n"
#
# Backup with borg
#
echo -e "\n######"
echo -e "\nBackup with Borg"
# The backup is created with two main parts:
# - The backups created separately (in this example Nextcloud)
# - Backup of the important directories of the system.
#
# Remarks
# - Do not add "--progress" when calling the script by cron!
borg create --stats \
$borgRepository::"${currentDate}" \
$borgBackupDirs \
--exclude $nextcloudDirBorgExclude
echo -e "\nDone\n"
echo -e "######\n"
#
# Cleanup
#
echo -e "\n\n###### Cleanup backup ######"
# All local backups are deleted again, as they were saved by borg backup
# Delete list of installed software
echo -e "\n######"
echo -e "\nDelete list of installed software"
rm "${localBackupDir}"/software.list
echo -e "\nDone\n"
echo -e "######\n"
# Delete local Nextcloud backup
echo -e "\n######"
echo -e "\nDelete local Nextcloud backup"
rm -r "${localNextcloudBackupDir:?}"/*
echo -e "\nDone\n"
echo -e "######\n"
# Borg prune
echo -e "\n######"
echo -e "\nCleanup borg backups"
# TODO: Borg should keep backups from the last 7 days (one week), 4 weekly backups (one month) and 6 monthly backups (half a year)
borg prune --progress --stats $borgRepository \
--keep-within=7d \
--keep-weekly=4 \
--keep-monthly=6
echo -e "\nDone\n"
echo -e "######\n"
#
# Misc
#
# Duration of backup
endTime=$(date +%s)
endDateReadable=$(date --date @"$endTime" +"%d.%m.%Y - %H:%M:%S")
duration=$((endTime-startTime))
durationSec=$((duration % 60))
durationMin=$(((duration / 60) % 60))
durationHour=$((duration / 3600))
durationReadable=$(printf "%02d hours %02d minutes %02d seconds" $durationHour $durationMin $durationSec)
echo -e "\n\n###### Server backup finished on ${endDateReadable} (${durationReadable}) ######\n"
# Free space on backup disk
echo -e "\nDisk usage:\n"
df -h ${backupDiskMount}
#
# Send mail to admin
#
# Important: An MTA has to be installed for sending mails.
# TODO: Add your own e-mail address here.
mail -s "Server backup finished" my@email.address < "${logFile}"
Das komplette Skript ist auch als Git-Repository auf Codeberg verfügbar: Linux-Server-Backup @ Codeberg
Bevor man das Skript also mühselig kopiert und einfügt, kann einfach das Repository gecloned werden:
mkdir -p /home/user/scripts/ git clone https://codeberg.org/DecaTec/Linux-Server-Backup.git
Wichtig: In diesem Skript sind alle Stellen, die individuell angepasst werden müssen mit einem TODO im Kommentar gekennzeichnet (die betrifft v.a. Verzeichnis-Angaben). Daher das Skript bitte nicht einfach übernehmen, sondern immer auf die eigenen Bedürfnisse anpassen.
Erläuterungen zum den einzelnen Schritten des Backup-Skripts (bitte auch die Kommentare im Skript selbst beachten):
- Als erstes werden Variablen zum Bedienen des Borg-Repositories gesetzt. Die betrifft v.a. das vergebene Passwort (Variable BORG_PASSPHRASE).
- Mit der Variable logDirectory wird das Verzeichnis festgelegt, in das pro Backup ein Log-File geschrieben wird.
- Mit localBackupDir wird das Verzeichnis angegeben, in das die lokalen Backups gespeichert werden – also in diesem Fall das gesondert angefertigte Nextcloud-Backup. Nach dem Aufruf von Borg werden die Inhalte dieses Verzeichnisses wieder gelöscht.
- Anschließend wird das Verzeichnis des Borg-Repositories angegeben (borgRepository) und die Verzeichnisse definiert, die später von Borg direkt gesichert werden sollen (borgBackupDirs).
- Es folgen die Verzeichnis-Angaben für das separate Nextcloud-Backup. Da /var/www ja schon direkt per Borg gesichert wird, ist das Web-Verzeichnis von Nextcloud später vom Backup auszuschließen (nextcloudDirBorgExclude).
- Anschließend erfolgt bei der Ausführung des Skripts die Überprüfung, ob dieses auch mit Root-Rechten ausgeführt wird.
- Nun beginnt die eigentliche Ausführung des Skripts: Es wird eine Liste der installierten Pakete im lokalen Backup-Verzeichnis gespeichert (sinnvoll, wenn das Backup auf einem anderen System wiederhergestellt werden sollte).
- Das Nextcloud-Backup wird dann einfach durch das Aufrufen des Nextcloud-Backup-Skripts erstellt.
- Es folgt der eigentliche Aufruf von Borg Backup.
- Anschließend werden die (temporären) lokalen Backups wieder gelöscht.
- Nun wird das Borg-Repository bereinigt. In diesem Beispiel sollen Backups der letzten 7 Tage, 4 wöchentliche Backups und 6 monatliche Backups behalten werden. Backup-Sets, die nicht mehr diesem Muster entsprechen, werden aus dem Respository gelöscht und dieses wird konsolidiert.
- Ganz am Ende des Skripts wird noch eine E-Mail versendet. Damit dies funktionieren kann, muss auf dem System ein MTA installiert sein (siehe Linux: Einfach E-Mails versenden mit msmtp).
Ist das Skript erstellt, werden die Zugriffsrechte noch eingeschränkt (hier ist ja das Passwort des Borg-Repositories gespeichert) und das Skript wird als ausführbar gekennzeichnet:
chmod 600 /home/user/scripts/server_backup.sh chmod +x /home/user/scripts/server_backup.sh
Das Backup-Skript kann nun für einen ersten Lauf manuell ausgeführt werden:
./home/user/scripts/server_backup.sh
Die erste Ausführung dauert in der Regel etwas länger, da alle zu sichernden Verzeichnisse und lokalen Backups gesichert werden müssen. Weitere Ausführungen des Skripts sollten dann aber deutlich schneller ablaufen.
Backups automatisieren
Das Anfertigen der Backups kann nun mittels Cron einfach automatisiert werden. Dazu muss lediglich für den Root-User ein Cronjob eingerichtet werden:
crontab -e
Hier fügen wir nun ganz unten z.B. folgende Zeile hinzu:
0 2 * * * /home/user/scripts/server_backup.sh > /dev/null 2>&1
Nun wird das Backup-Skript jede Nacht um 02:00 aufgerufen.
Hinweis: Der Pfad zum Skript muss in der Crontab immer absolut (also mit dem kompletten Verzeichnis-Pfad) angegeben werden.
Wenn das Skript zu einem anderen Zeitpunkt ausgeführt werden soll, kann ich die Seite contab guru empfehlen: Dies ist eine Seite zum einfachen Erstellen von Crontab Zeitplänen. Hiermit wird es einfacher, die Syntax für den Zeitplan eines Cronjobs zu erzeugen.
Off-Shore Backups
Das Backup kann mit diesem Skript an jeden beliebigen Ort gespeichert werden, der auf der lokalen Maschine verfügbar ist (z.B. eine zweite interne Festplatte, ein NAS, etc.). Nun kann man sich Gedanken über ein „Offshore-Backup“ machen: Dies bedeutet, dass man ein weiteres Backup anfertigt, welches jedoch örtlich getrennt vom ersten Backup ist. Im einfachsten Fall ist dies ein Backup auf einer externen Festplatte, welche bei Freunden/Verwandten gelagert wird, oder auch ein Backup in eine Cloud. Sinn und Zweck hierbei ist die Datensicherheit im Katastrophenfall (z.B. bei Hausbrand, Überschwemmung, Diebstahl, etc.).
Das Borg-Repository kann dazu in seiner Gesamtheit an einen beliebigen Ort kopiert werden und schon hat man ein zweites identisches Backup. Durch die Verschlüsselung des Backups muss man sich hierbei auch keine Gedanken um unbefugten Zugriff machen: Selbst, wenn die externe Festplatte in die falschen Hände gerät, kann ein Dritter keinen Zugriff auf die Daten des Backups erlangen.
Um das Borg-Repository (/media/hdd2/server_backup) beispielsweise auf eine externe Festplatte (hier z.B. gemountet unter /media/hdd_ext) zu kopieren, kann einfach rsync verwendet werden:
rsync -ahP --delete --stats /media/hdd2/server_backup /mnt/hdd_ext
Das zweite Backup ist dann eine identische Kopie des ersten Backups und kann genau so zur Wiederherstellung verwendet werden.
Dies kann dann auch auf einem anderen Rechner geschehen. Die einzige Voraussetzung ist eine Installation von Borg Backup und das Passwort des Original-Repositories.
Backups wiederherstellen
Ein Backup anzufertigen ist die eine Sache. Bevor man im Problemfall darauf angewiesen ist, sollte man sich auf jeden Fall damit vertraut machen, wie man die Daten aus dem Backup wiederherstellen kann.
Für die Wiederherstellung von Dateien und Verzeichnissen gibt es z.B. den Befehl borg extract (siehe Borg Dokumentation).
Ich gehe hier aber meistens einen anderen Weg, da dies für mich persönlich komfortabler ist. Zunächst kann man sich eine Liste an „Backup-Sets“ anzeigen lassen:
borg list /media/hdd2/server_backup/borg/
Nach der Eingabe des Passworts werden alle verfügbaren Backup-Sets aufgelistet (hier rot markiert):
Ein Backup-Set kann nun einfach in das Dateisystem gemountet werden:
mkdir -p /mnt/borg borg mount /media/hdd2/server_backup/borg::20191006_020001 /mnt/borg
Wieder wird nach dem Passwort gefragt und anschließend ist das komplette Backup (mitsamt Unterverzeichnissen) unter /mnt/borg gemountet und man kann mit normalen Dateioperationen darauf zugreifen.
Um nun beispielsweise eine einzelne Datei auf dem Backup zu extrahieren, kann ganz einfach cp verwendet werden:
cp /mnt/borg/etc/nginx/conf.d/HTTP-Gateway.conf /etc/nginx/conf.d/HTTP-Gateway.conf
Nach dem Extrahieren der benötigten Dateien aus dem Backup kann das Backup-Set wieder ausgehängt werden:
borg umount /mnt/borg
Wenn nun keine einzelnen Dateien, sondern das Backup einer kompletten Applikation wiederhergestellt werden muss, wird das Backup der Anwendung aus dem Borg-Repository extrahiert. Anschließend wird dies separat wiederhergestellt. Siehe beispielsweise die Restore-Anweisungen für Nextcloud.
Troubleshooting
Das hier gezeigte Skript ist natürlich nur ein Beispiel und kann beliebig erweitert werden. Damit kann das Skript auch durchaus umfangreich werden. Wenn das Skript dann nicht richtig funktionieren sollte, ist der erste Schritt immer die Kontrolle der Logs, die durch das Skript angelegt werden. Sollte dies nicht zur Lösung des Problems führen, sollten die einzelnen Schritte, die im Skript enthalten sind, einzeln und in genau der Reihenfolge auf der Kommandozeile ausgeführt werden. Hier sollte dann zumindest der Schritt identifiziert werden können, ab dem das Skript „aus dem Ruder läuft“. Wenn das Problem gefunden wurde, sollte anschließend das Skript dementsprechend angepasst werden.
Fazit
Dieser Artikel hat eine einfache und effiziente Möglichkeit skizziert, wie ein Linux-System gesichert werden kann. Das bereit gestellt Skript kann als Ausgangspunkt für eigene Backup-Strategien verwendet werden.
Wenn das System erst einmal eingerichtet wurde (und das Wiederherstellen der angefertigten Backups getestet wurde!), können die Backups automatisiert werden, so dass man hier in Zukunft nicht mehr viel Zeit investieren muss. Im Problemfall kann man dann ganz einfach auf die erstellten Backups zurückgreifen.
Habt ihr euch für euren Server auch schon eine Backup-Strategie ausgedacht? Wie sieht diese im Detail aus? Hinterlasst mir dazu doch einfach einen Kommentar.
Weiterführende Artikel
- Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript
- WordPress: Backups erstellen und wiederherstellen – manuell oder per Skript
- Eigener Firefox Sync Server mit nginx
- Linux: Einfach E-Mails versenden mit msmtp
Hallo Jan,
Ist denn Veeam Backup Agent for Linux nicht einfacher einzurichten? Zumindest für die die keine besonderen Anpassungen am Backup vornehmen wollen …
Hi,
ich persönlich setze lieber auf quelloffene Lösungen.
Ansonsten wäre Veeam sicher auch ein guter Ansatz.
Gruß,
Jan
Hi,
danke für das Tutorial. Ich benutze lieber Duplicati, dass lässt sich einfacher mit einer GUI verwalten.
Gruß Tobi
Hallo Jan,
vielen Dank für diese 1A Anleitung, alles hat wie beschrieben super funktioniert. Schöne Feiertage und einen Guten Rutsch ins neue Jahr.
Hallo Jan,
Hast du dir einmal Vorta für Borg (https://vorta.borgbase.com/) als GUI angeschaut? Was denkst du darüber?
Grüsse
Hi Frank,
nein, das sagt mir nichts. Da ich (speziell für diesen Artikel) eher auf einem Server unterwegs bin, fällt hier eine GUI natürlich weg. Mir persönlich reicht hier auch der Zugriff per Kommandozeile. Über Scripts lässt sich dass alles auch gut automatisieren.
Gruß,
Jan
Hallo Jan,
vielen Dank für das ausführliche Tutorial und die Skripte. Ich hab eine Frage zur Strategie.
Wenn du in dem Beispiel erst die Nextcloud-Ordner mit tar komprimierst (über das nextcloud-backup Skript) und dann diese Archive mit Borg sicherst, ist doch der Vorteil des Deduplizierens dahin, oder verstehe ich dein Beispiel falsch?
Viele Grüße,
Daniel
Hallo Daniel,
genau das dachte ich ursprünglich auch, da ja z.B. die Sicherung (das Archiv) des NC-Datenverzeichnisses sich ja immer ändert.
Borg sichert das jedoch nicht Datei-weise, sondern Block-weise. Daher funktioniert in diesem Szenario die Deduplizierung ausgesprochen gut. Ansonsten hätte ich das an meinen eigenen Cloud-Instanzen schon längst gemerkt, wenn die Backups hier „explodiert“ wären.
Gruß,
Jan
Hallo Jan, Danke auch von mir für das tolle Tutorial und Script. Das Erspart einiges an Zeit und Nachforschungen.
Leider passiert bei mir scheinbar aber genau das, was Daniel anspricht. An allen drei Backup Tagen war meine Borg Backup ca. 2GB+ groß, obwohl sich im Data Verzeichnis „nichts“ geändert hat. Ich hätte erwartet, dass das Erste Backup die volle Größe hat und die weiteren Backups entsprechend kleiner sind. Das war bei mir jedoch nicht der Fall. *verwundert*
Ich ändere aktuell das Script ab, so das tar nichts mehr verpackt und die Files einzeln in den Verzeichnissen liegen. Ich hoffe das hat den erhofften Effekt der Inkrementalität.
Hi Steven,
das ist aber echt ungewöhnlich, ein solches Verhalten konnte ich noch nicht beobachten.
Ich bitte um kurze Rückmeldung, ob das „Nicht-Packen“ der Dateien hier eine Änderung erbringt.
Gruß,
Jan
Hi Jan, sorry für die späte Antwort. Ich habe meinen Server zu einem anderen Hoster umgezogen. Hier habe ich dann das orig. Script von dir ein paar Tage laufen lassen, um zu sehen wie es sich verhält.
Das Nextcloud Data Verzeichnis ist in der Zeit von ca. 4GB auf 6gb angewachsen. Die Backups aber wesentlich mehr.
„du -h“ sagt aktuell:
5.8G /…/data
584M /var/www/nextcloud/
Borg sagt:
Original size Compressed size Deduplicated size
All archives: 3.84 GB 3.85 GB 3.85 GB
All archives: 7.83 GB 7.85 GB 4.98 GB
All archives: 11.91 GB 11.93 GB 6.19 GB
All archives: 16.03 GB 16.05 GB 10.32 GB
All archives: 20.85 GB 20.89 GB 15.15 GB
All archives: 25.68 GB 25.73 GB 15.49 GB
All archives: 31.70 GB 31.76 GB 21.45 GB
All archives: 33.87 GB 33.94 GB 23.67 GB
All archives: 35.97 GB 36.05 GB 25.90 GB
All archives: 37.99 GB 38.08 GB 25.04 GB
All archives: 39.97 GB 40.07 GB 21.20 GB
All archives: 46.07 GB 46.18 GB 21.43 GB
All archives: 47.34 GB 47.46 GB 21.50 GB
Wie man sehen kann findet durchaus eine gewisse Deduplizierung statt (Deduplicated size wächst manchmal nicht stark, aber zwischendrin sind dann noch immer mal Sprünge von 5GB zu beobachten) Die „Original Size“ klettert einfach weiter und weiter..? (oder verstehe ich hier irgendwas falsch?)
Ich würde bei einem 6GB Data Verzeichnis erwarten, dass es nicht Signifikant größer wird, wenn sich dort nur kleine Änderungen stattfinden, oder?
Die Variante mit dem „Nicht-Packen“ habe ich auf dem neuen Server noch nicht getestet.
Hi Steven,
danke für deine Nachforschungen.
Ich achte da eigentlich immer nur auf die „deduplicated size“, da dies mehr oder weniger den realen Speicher aufzeigt, die das Backup einnimmt.
Richtig interessant wäre nun ein Test ohne vorheriges Zippen der Dateien. Hast du noch vor, diese Tests auch noch durchzuführen?
Gruß,
Jan
Hi Jan, ich habe jetzt über eine gewisse Zeit das Backup ohne Komprimierung probiert und da war immer komplett nachvollziehbar.
Heute wollte ich dann endlich einen 1zu1 Vergleich machen und habe die Komprimierung wieder eingeschaltet. Und wie das immer so ist… ich kann die großen Sprünge vom letzten mal nicht reproduzieren. Ich habe ein paar Files hochgeladen, verschoben und gelöscht und danach jeweils immer ein Backup angestoßen. Diesmal funktioniert alles wie du sagtest. Also trotz Komprimierung keine großen Sprünge. Ich habe keine Ahnung was damals anders war oder was ich falsch gemacht habe… ;)
Sollte es doch nochmal passieren, melde ich mich.
https://cloud.finsterberge.de/index.php/s/5iCz3Y7ypybxTjH
Hi Steven,
OK, dann hat sich das Problem ja in Luft aufgelöst.
Auf jeden Fall danke für deine Versuchsreihe und die Daten. Finde ich auch immer sehr interessant.
Gruß,
Jan
Hallo Jan,
ich bin dabei meine Backups auf BorgBackup umzustellen.
Habe bisher RSnapshot verwendet (dies wird aber nicht mehr so richtig gewartet).
Dazu habe ich eine Frage:
Warum sicherst du die NC-Daten zuerst in einen Temp-Ordner um sie dann mit BorgBackup zu sichern ?
Ich würde meine NC-Database über ein Script zwischensichern und BorgBackup direkt auf /var/www/nextcloud laufen lassen.
LG
Tom
Hi Tom,
man muss NC nicht separat sichern, das Daten-Verzeichnis kann auch einfach Teil des Borg Backups sein (wenn die DB separat gesichert wird).
Warum ich das etwas anders mache, hat folgende Gründe:
Aus diesen Gründen sichere ich lieber alles separat und schalte das dann alles möglichst schnell wieder „online“.
Gruß,
Jan
Hallo Jan,
bin gerade dabei, auch mithilfe deiner Anleitung, meinen Server auf BorgBackup-Sicherungen umzustellen.
Dabei sind mir zwei Sachen aufgefallen :
– localBackupDir hast du in borgBackupDirs und bei „borg create“ angegeben
– du empfiehlst mit rsync ein borgbackup-Repository zu clonen. Das wird in der Borg-Doku nicht empfohlen weil man sich damit evtl. Festplatten-Datenfehler von der Repo holt. Stattdessen wird empfohlen ein zweites Borg-Repo anzulegen.
Gruss
Tom
Hallo Tom,
bei Punkt 1 hast du recht, das habe ich gleich angepasst (auch im Git-Repo). Danke für den Hinweis!
Bei Punkt 2 muss man sich überlegen, was der Zweck dieser Kopie (bzw. dem zweiten Backup-Repo) ist. In meinem Fall ist das nur eine zusätzliche Absicherung, falls die Platte mit dem originalen Repo mal ausfallen sollte. Wenn natürlich mit dem Borg-Repo (Platte 1) was schief gehen sollte, dann sind diese Sachen auch in der Kopie enthalten. Das ist aber eine bewusste Entscheidung.
Gruß,
Jan
Hallo Jan
Du beschreibst in Deinem Artikel, dass man ein Archiv auch mounten kann und dann die Dateien von dort dorthin kopieren, wo man will. Ich habe das versucht. Im Mount-Verzeichnis haben alle Dateien ein Schloss-Icon. Wenn ich dann die Datei kopiere, dann haben die Dateien am Zielort auch wieder ein Schloss-Icon. Da normalerweise Dateien kein Schloss-Icon haben, frage ich mich, ob diese Schloss Dateien irgendetwas besonderes sind.
Ich kann z.B. Textdateien auch öffnen, aber alle Dateien haben jetzt ein Schloss-Icon.
(Hinweis: Ich habe das Backup nicht verschlüsselt. Ich habe das Backup auf eine externe Festplatte gemacht.)
Ich hätte erwartet, dass die Dateien nach dem Kopieren das Schloss-Icon verlieren.
Hallo Kaya,
was meinst du mit „Schloss-Icon“? Ich vermute mal, dass du hier irgendwie mit einer grafischen Oberfläche vorgehst, oder?
Kopiere besser per Konsole mit rsync. Achte auch darauf, dass die Rechte der Verzeichnisse/Dateien mit kopiert werden.
Gruß,
Jan
Hallo Jan,
mir ist jetzt bei meinen Backups nach deiner Anleitung folgendes aufgefallen :
Dein Script NextcloudBackup.sh sichert immer in einem Unterverzeichnis (Zeitstempel), z.B.
… /nextcloud/20200403_030006/nextcloud-db.sql
… /nextcloud/20200404_030001/nextcloud-db.sql
Ich denke nicht, dass hier die Deduplizierung funktioniert !
Borg diff liefert dann z.B. 4GB removed und 4GB added.
Ich denke, man muss in diesem Fall NextcloudBackup.sh anpassen so dass es nicht in ein Zeistempel-Unterverzeichnis sichert !
Gruss
Tom
Hi Tom,
also ich habe das bei mir auch so eingerichtet und die Daten bei den Backups „explodieren“ nicht (was man erwarten könnte, wenn die Deduplizierung nicht funktionieren würde).
Er geht hier glaube ich nicht nach Dateinamen, sondern auch nach Dateiinhalten vor.
borg diff listet glaube ich nur die „Rohdaten“ auf, wie bei einem Backup hinzugekommen/entfernt wurden.
Gruß,
Jan
Hallo Jan,
aus welchen Gründen legst du das Skript unter /home/user/scripts/ und nicht direkt unter /root/ ab?
Gruß Stefan
Hi Stefan,
wo das Script auf der Platte liegt, ist eigentlich egal. Ich habe meine „Script-Sammlung“ eben unter
/home/<user>/scriptsabgelegt.Gruß,
Jan
Vielen Dank für die fundierte Anleitung. Auf Basis dessen bin ich nun auch auf Borg für mein Backup-Thema umgestiegen.
Ich habe noch zwei Sachen in mein Script eingebaut:
1. Das sichtbare Setzen des Password habe ich mit „secret-tool“ vermieden. Das Password habe in die Schlüsselverwaltung abgelegt und hole es dann von dort wieder ab – man weiß ja nie …
https://askubuntu.com/questions/262698/how-do-i-get-passwords-from-the-keyring-in-the-terminal-for-usage-in-scripts
2. Da ich keinen eigenen Mail-Server habe, habe ich es über „curl“ realisiert:
https://stackoverflow.com/questions/8260858/how-to-send-email-from-terminal
Dies hat bei mir auf Anhieb sofort funktioniert.
Hallo Karl,
danke für die Hinweise. Ist sicher auch für andere ganz interessant.
Gruß,
Jan
Hallo,
meine Nextcloud läuft auf nem VServer. Ich hab noch nen 2. Server auf den ich das Backup schieben könnte. Alternativ auf meine NAS zu Hause.
Wie bringe ich denn Borg die Pfade zu den Zielen bei?
Danke
Markus
Hi Markus,
du könntest die Server einfach per Samba oder NFS verbinden. Dann brauchst du allerdings ein VLAN beim jeweiligen Anbieter, da Samba/NFS nicht über das Internet „geroutet“ werden können.
Wenn dies nicht möglich sein sollte (z.B. beide Server können nicht über VLAN verbunden werden), dann kann Borg auch Remote per SSH ausgeführt werden (siehe hier).
Gruß,
Jan
Hallo Jan,
vielen Dank . Hatte gestern schon geantwortet, aber die Antwort ist anscheinend nicht angekommen.
Zwischen den Servern (Netcup) gibts ein VLAN. Hab ich aber noch nicht eingerichtet (was man wohl muss, soviel ich weiß). Mit Samba und NFS kenne ich mich ehrlich gesagt (noch) nicht aus. Außerdem hat der 2. Server relativ wenig Speicher.
Ich würde daher meine NAS zu Hause bevorzugen. Also entweder direkt auf die NAS Speichern (wie aus www erreichbar) oder per Download der Borg Files.
VG
Markus
Hi Markus,
ja, VLAN muss explizit bestellt (auch wenn die 100MBit/s Variante kostenlos ist) und eingerichtet werden.
Wenn du das ganze zu Hause speichern möchtest, fällt aber NFS oder Samba raus. Dann geht – wenn möglich – den Weg über Borg/SSH.
Gruß,
Jan
Hallo Jan,
Danke mal wieder für dieses großartige Tutorial und das Skript!! Es läuft super seit Wochen.
Eine Frage: Ich hätte gern tatsächlich ein ortsungebundenes zusätzliches Backup auf USB – am liebstens auch per borg,
Nun suche ich neben dem eigentlicheen Backup-Skript, eines, das als erstes die Abfrage startet, ob das USB-Laufwerk überhaupt angeschlossen ist. Das aus dem Ubuntuusers-Forum funktioniert leider nicht (https://forum.ubuntuusers.de/topic/rsync-skript-aus-wiki-fuer-backup-von-borg-rep/#post-9281006).
Weißt Du, wo ich ein Skript für diese Abfrage her bekommen kann?
Herzliche Grüße
Jo
Hallo Jan,
dank deiner vielen Anleitungen habe ich eine für mich zufriedenstellende Instanz erstellen können. Dadurch, dass ich echt mehrere Tage darin investiert habe diese zum Laufen zu bringen, würde ich gerne ein „Installationsbackup“ meines LEMP-Stacks der „Stunde Null“ machen (alle Programme). Ist sowas möglich ein solches Backup zu erstellen? Ein einfaches kopieren der root-Ordner und im Schadensfall zurück kopieren der Dateien reicht doch nicht aus oder (wegen der EFI-Einstellungen etc..)? Hast du einen Vorschlag wie man ein solches „Stunde Null“ Backup erstellen könnte?
Hi,
eine ganz einfache Lösung gibt es hier leider nicht. Du könntest dir hier mal fsarchiver. anschauen.
Auf der anderen Seite reichen ja eigentlich alle Dateien, die du während der Einrichtung angepasst hast (also vieles unter /etc/). Mit einer solchen Sicherung könntest du wieder recht schnell einen neuen Server hochstellen, indem zu den LEMP-Stack einfach installierst und die Konfigs aus dem Backup übernimmst.
Gruß,
Jan
Hallo Jan,
danke. Den fsarchiver werde ich mir mal anschauen. Bei hunderten Dateien, welche geändert werden mussten, verliert man schnell den Überblick wo die alle final liegen. Meinst du das funktioniert, alle Dateien und Ordner zu sichern, die NVME- oder SSD-Karte zu formatieren und dann alles wieder draufzukopieren ohne irgendwelche Installationen starten zu müssen? Oder gibt es da untere Abhängigkeiten, (logische Verknüpfungen, EFI-/Bios-Einstellungen, etc.) oder Software- und Hardwarelayer, welche ein solches Vorgehen grundlegend unmöglich machen?
Hi Sascha,
also einfach ein Backup „über das Dateisystem wiederherzustellen“ wird leider nicht funktionieren. fsarchiver würde ich auch erst einmal mit einer VM verproben, ob im Fehlerfall auch wirklich der Restore funktioniert.
Im Normalfall recht es aber, die entsprechenden Konfigurationsdateien zu sichern. Im Fall des Falls kann man ein Linux-System schnell neu aufsetzen (inkl. LEMP-Stack). Mit den gesicherten Konfigurationen ist das System dann im Normalfall schnell wieder funktionstüchtig.
Gruß,
Jan
Hallo Jan,
ich habe mir mal bei Hetzner die Storage-Box angeschaut.
https://www.hetzner.com/de/storage/storage-box
Kann diese (Storage-Box) ohne Problme mit deinem Backup-Skript verwendet werden.
Ich denke da an SSH.
Eine Backuplösung für die NC in Verbindung mit der Storage-Box habe ich bei Carsten Rieger gesehen, jedoch ohne Backup des Servers.
Vielen Dank
Gruß Hans
Hi Hans,
ja, das funktioniert genau so. Borg wird dann eben nur über SSH angesprochen.
Ich sichere meine Server genau so mit einer StorageBox.
Gruß,
Jan
Hallo Jan,
vielen Dank.
Gruß Hans