Backups sind wichtig. Diese Tatsache ist sicher niemandem neu, aber die Anforderungen sind vielfältig: Sie sollten regelmäßig - am besten automatisiert - erzeugt und verifiziert werden, auf unterschiedliche Speichermedien, mit besonderen Hardware-Anforderungen. Backup-Systeme sollten nicht permanent mit dem gesicherten Computer verbunden sein - dies schließt natürlich auch via Netzwerk zugängliche NAS/SAN-Systeme ein - und im Falle von “Offlinemedien”, nach der Sicherung, an unterschiedlichen Orten gelagert werden. Dort dann unter idealen klimatischen Bedingungen, um einer vorzeitigen Alterung und bit rot vorzubeugen, am besten bei regelmäßiger Stromzufuhr.
Lokale Sicherungen
Je nach Wichtigkeit der zu sichernden Daten unterscheidet sich natürlich auch der Anspruch an das geeignete Backup-Konzept, dennoch bleibt festzuhalten, dass lokale Sicherungen insbesondere zur “Langzeitarchivierung” garnicht so einfach umzusetzen sind.
Off-site Sicherungen (in der Cloud)
In jedem Fall lohnt einmal der Blick in Richtung Cloud. Cloudspeicher wird stetig günstiger und viele Provider bieten bereits seit geraumer Zeit fertige cold storage Lösungen zur Langzeitarchivierung an, die sich bislang jedoch eher an Firmenkunden richten.
Anforderungen
Ein äußerst gewichtiger Punkt, gerade bei Online-Backups, ist neben den regulären Anforderungen wie die exakte Planung der Sicherungsintervalle und die Integrität der Daten, die Sicherheit ebendieser. Kurzgesagt es gelten bei Sicherungen die über das Internet - theoretisch - von jedermann zugänglich sein könnten, höhere Anforderungen an den Zugriffsschutz.
Um diesem Anspruch gerecht zu werden, müssen u.a. folgende Punkte sichergestellt sein:
- Der Zugriff auf die Backup-Daten wird reglementiert (Gruppenrichtlinien, Benutzeraccounts, Berechtigungshierarchien, ..)
- Die Daten selbst sind durch (starke) Verschlüsselung geschützt
- Obiges schließt auch die Transport-, bzw. Kommunikationskanäle während des Sicherungs- und Zugriffprozesses ein
- Die lokalen, zu sichernden Systeme sind ebenfalls Teil der Kette und sollten als eben diese betrachtet werden. Wenn beispielsweise die Workstation kompromittiert wurde, muss es dem Angreifer durch geeignete Maßnahmen erschwert werden Schreibzugriff auf Backuparchive zu erhalten.
Info: IT-Sicherheit ist immer ein dynamische Prozess, der ständig weiterentwickelt und gelebt werden muss. Anforderungen ändern sich, ebenso wie Verschlüsselungsalgorithmen. Schwachstellen werden entdeckt und Software veraltet. Man kommt nicht umhin, von Zeit zu Zeit sein Backup-System anzupassen.
Ich gehe in dieser Anleitung nicht weiter darauf ein, wie man ein komplettes Backup-Konzept erstellt, vielmehr möchte ich Anreize für eine solide Basis geben, die man einfach an die eigenen Bedürfnisse anpassen kann.
BorgBackup
BorgBackup (kurz: Borg) ist eine in Python und C (Cython) geschriebene Software-Lösung für die Erstellung von Sicherungen, deren Hauptaugenmerk auf folgenden Punkten liegt:
- Effiziente Speichernutzung
- Backup-Geschwindigkeit
- Datensicherheit durch starke Verschlüsselung
- Kompression
- Unterstützung für SSH, für schnelle Off-site Backups
- Einfacher, nutzerfreundlicher Zugriff auf Backup-Archive via FUSE
- Multi-Plattform-Unterstützung (Linux, MacOS, BSD, Windows via Cygwin/WSL)
- Open Source Software unter der BSD Lizenz!
Borg eignet sich aus diesen Gründen wunderbar für lokale, wie auch für Off-site Backups. Das Borg-CLI und die Dokumentation ist herausragend, theoretisch bräuchte man für sämtliche Sicherungen nichts anderes. Dennoch gibt es zahlreiche Text- und GUI-basierende Frontends.
Borg frontend borgmatic
borgmatic beispielsweise ist nicht nur ein simpler Wrapper um Borg, sondern erweitert das System um eine konfigurations-geführte Steuerung und Automatisierung. Das ist insbesondere bei der Sicherung von Servern sehr hilfreich, kommt uns aber auch am Desktop-PC gelegen.
Lokale Backups mit borgmatic und Snapper
In folgendem Beispiel werde ich beschreiben, wie ich manuelle, inkrementelle Vollsicherungen meiner Workstation erstelle, die - selbstverständlich - mit Arch Linux betrieben wird. Allerdings lässt sich die Anleitung leicht auf andere Systeme übertragen!
Anforderungen
Es gibt keine speziellen Anforderungen, wir brauchen nur eine überschreibbare, externe Festplatte. Aus Gründen der Datenintegrität sollte dies allerdings eher kein NAND/SSD-Flash-Speicher sein.
Als Dateisystem für den Datenträger verwende ich Btrfs. So bin ich zusätzlich in der Lage Dateisystem-Snapshots, ganz komfortable via Snapper - ein von SUSE entwickeltes Tool für Btrfs und LVM - zu erstellen.
Vorbereitung der externen Festplatte
Wichtig: Der externe Datenträger wird überschrieben. Bitte zweimal prüfen, ob die Operationen auf dem richtigen Gerät ausgeführt werden!
Mit gdisk habe ich eine neue GPT-Partitionstabelle erstellt mit einer Partition, die den gesamten Platz der Festplatte einnimmt.
Folgendermaßen könnte es aussehen:
sudo gdisk -l /dev/sdX
Number Start (sector) End (sector) Size Code Name
1 2048 1953525134 931.5 GiB 8300 Linux filesystem
Danach erzeuge ich das Dateisystem, mit dem Label “backup”, auf der neuen Partition und
binde sie anschließend unter /mnt ein.
Info: Nicht wundern; für diesen Test hatte ich nur ein NVMe Modul zur Verfügung und
musste dies bei den Parametern für den mount Befehl berücksichtigen.
Bitte passt die Parameter euren Gegebenheiten an!
sudo mkfs.btrfs --force --label backup /dev/sdX1
sudo mount -o defaults,x-mount.mkdir,compress=lzo,ssd,noatime \
-t btrfs LABEL=backup /mnt
Konfiguration von Snapper
Um snapper einzurichten, erzeuge ich zwei Btrfs-Subvolumes:
sudo btrfs subvolume create /mnt/@
sudo btrfs subvolume create /mnt/@snapshots
Danach hänge ich das Btrfs rootvol wieder aus und erstelle zwei Verzeichnisse in die später die Subvolumes eingebunden werden:
sudo umount -R /mnt
sudo mkdir -p /mnt/backup/.snapshots
sudo chmod a+rx /mnt/backup/.snapshots
Als nächstes fügen wir zwei Einträge unserer /etc/fstab Datei hinzu, die wie folgt aussehen könnten:
# Backup
LABEL=backup /mnt/backup btrfs subvol=@,defaults,x-mount.mkdir,compress=lzo,ssd,noatime,noauto,nofail,x-systemd.device-timeout=1ms 0 2
LABEL=backup /mnt/backup/.snapshots btrfs subvol=@snapshots,defaults,x-mount.mkdir,compress=lzo,ssd,noatime,noauto,nofail,x-systemd.device-timeout=1ms 0 2
Der erste Eintrag hängt das primäre Btrfs subvol @ unter /mnt/backup ein und der zweite subvol @snapshots unter /mnt/backup/.snapshots.
| Befehl | Erklärung |
|---|---|
| x-mount.mkdir | Erstelle das Zielverzeichnis, wenn nicht vorhanden |
| nofail | Standardmäßig wird versucht alle Geräte in /etc/fstab einzubinden, wenn dies fehlschlägt gibt es einen Fehler, diese Option unterbindet das |
| x-systemd.device-timeout=1ms | Beim Bootvborgang wird nicht lange auf das Gerät gewartet |
Dann können wir die Btrfs-Volumes einbinden:
sudo mount /mnt/backup
sudo mount /mnt/backup/.snapshots
Info: Wenn man sudo snapper create-config <subvolume> für die initiale Generierung einer Snapper Konfiguration verwendet,
dann wird Snapper u.U. ein unnötiges Btrfs-Subvolume anlegen. Aus diesem Grund überspringe ich den Schritt und lege
meine Konfiguration direkt in /etc/snapper/configs/ ab.
Meine Konfiguration sieht wie folgt aus:
# Subvolume to snapshot
SUBVOLUME="/mnt/backup"
FSTYPE="btrfs"
QGROUP=""
SPACE_LIMIT="0.5"
FREE_LIMIT="0.2"
# Users and groups allowed to work with config
ALLOW_USERS="ff0x"
ALLOW_GROUPS="trickkiste"
SYNC_ACL="no"
BACKGROUND_COMPARISON="yes"
NUMBER_CLEANUP="yes"
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="50"
NUMBER_LIMIT_IMPORTANT="10"
TIMELINE_CREATE="yes"
TIMELINE_CLEANUP="yes"
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="10"
TIMELINE_LIMIT_DAILY="10"
TIMELINE_LIMIT_WEEKLY="0"
TIMELINE_LIMIT_MONTHLY="10"
TIMELINE_LIMIT_YEARLY="10"
EMPTY_PRE_POST_CLEANUP="yes"
EMPTY_PRE_POST_MIN_AGE="1800"
Jetzt kann man einmal verifizieren, ob Snapper die Konfiguration findet:
sudo snapper list-configs
Config | Subvolume
-------+------------
backup | /mnt/backup
Testweise können wir manuell einen initialen Snapshot des leeren, primären Volumes erstellen:
sudo snapper -c backup list
# | Type | Pre # | Date | User | Cleanup | Description | Userdata
---+--------+-------+-----------------------------+------+---------+-------------------+---------
0 | single | | Mo 02 Feb 2021 21:32:57 CET | root | | current |
sudo snapper -c backup create --description "backup (by-hand)"
sudo snapper -c backup list
# | Type | Pre # | Date | User | Cleanup | Description | Userdata
---+--------+-------+-----------------------------+------+---------+-------------------+---------
0 | single | | | root | | current |
1 | single | | Mo 02 Feb 2021 21:34:57 CET | root | | backup (by-hand) |
Snapper kann allerdings noch viel mehr!
Konfiguration von borgmatic
Eine komplette Beispielkonfiguration für borgmatic, mit allen verfügbaren Optionen, findet ihr hier.
Nachfolgend nur die von mir geänderten Werte:
location:
source_directories:
- /bin
- /boot
- /dev
- /etc
- /home
- /lib
- /lib64
- /opt
- /root
- /sbin
- /srv
- /usr
- /var
repositories:
- /mnt/backup/data
exclude_patterns:
- '*.log'
storage:
encryption_passcommand: /usr/bin/su "ff0x" -c '/usr/bin/pass backup/borg/backup-1 | /usr/bin/head -n 1'
compression: lz4
keep_weekly: 4
keep_monthly: 12
keep_yearly: 1
hooks:
before_backup:
- echo "Mounting backup drive.."
- mount /mnt/backup
- mount /mnt/backup/.snapshots
after_check:
- echo "Creating BTRFS snapshot using Snapper.."
- /usr/bin/snapper -c backup create --description "backup (planned)"