Backup und Restore

Table of Contents

Tägliches Backup

  • Benutzer- und Projekt-Daten der letzten 3 Monate gibt es als täglichen AFS-Dump auf dem Backup-Server; die Sicherung wird durch BackupAFS getriggert. Um an die Daten zu gelangen, ist Operatorunterstützung notwendig.
  • Benutzer- und Projekt-Daten vom letzten Tag: AFS Backup Volume; gemountet nach ~/.oldfiles/ und daher ohne Hilfe des Operators zu verwenden
  • Konfigurationsdaten werden mit BackupToDisk gesichert.
  • Daten des ROOT-Benutzers, WWW-Server, Samba-Server, …, die nicht in den Homedirectories liegen werden mit BackupToDisk gesichert.
  • MySQL- Datenbanken werden mit BackupToDisk gesichert.
  • Images der virtuellen Maschinen werden mit BackupToDisk gesichert.

Archiv für katastrophale Ereignisse

Archiv-Sicherungen werden von backup/backup_archive (Acount-Daten, Datenbanken, AFS unter Verwendung von afs_admin_tools/afs_backup_full_dump) auf externen Festplatten angelegt und außer Haus gelagert.

  • Backup einmal am 1. Montag im Monat
  • in ungeraden Monaten auf Platte 1, in geraden Monaten auf Platte 2
  • Anhängen des externen Speichersystems an Firewire/USB
  • Start mit /usr/local/sbin/backup_archive <device> auf einem Rechner
    • mounted die externe Platte
    • sichert alle MySQL-Datenbankserver
    • sichert die Kerberos und NIS-Daten
    • sichert die AFS Protection Database
    • ruft /usr/local/sbin/afs_backup_full_dump mit geeigneten Parametern um alle Volumes (außer scratch) zu sichern
    • Protokoll wird per E-Mail versandt
    • unmount
  • Speicher abhängen und mit nach Hause nehmen!

An sich gibt das Programm aus, welche Daten gerade gesichert werden; der Fortschritt beim Backup kann zusätzlich auf einem anderen Terminal verfolgt werden:

DEV=sde1 
watch "ls -ltr /media/$DEV/ITP-backup/; echo; \
       ls -ltr /media/$DEV/ITP-backup/AFS-Volumes/ |tail -n 25; \
       echo ; df -lh /media/$DEV/"

Geräteschaden

  • hat das RAID geholfen?
  • Geräteschaden an Datenplatten: AFS-Dump vom Vortag

Wiederaufsetzen nach einer Katastrophe

Wenn die vorhandene Infrastruktur (z.B. Brand im ServerRaum) komplett zerstört wurde, kann von 2 unterschiedlichen externen Festplattensystemen (siehe “Archiv”) der gesamte Datenbestand der AFS-Server wieder eingespielt werden:

  • Fileserver kaufen und mit OpenAFS installieren
  • externe Platte mitbringen, mounten und die Volumes aus “mnt/ITP-backup” mit vos restore rücksichern - der Name des dump files und des volumes ist gleich.
for VOL in $MNT/ITP-backup/*; do
    vos restore -server <machine> \
                -partition <part> \
                -name $VOL \
                -file $MNT/ITP-backup/$VOL \
                -overwrite f \
                -localauth
done

Bare Metal Recovery

Bei Beschädigungen des System werden die Computer an den Arbeitsplätzen nach der Reparatur neu installiert - Backup lohnt sich hier nicht.

Für das “Bare Metal Recovery” bei defekten Server-Systemen werden einige Alternativen evaluiert, mein Favorit ist derzeit Partition Image - allerdings ist eine Neuinstallation durch die Unterstützng der ConfigurationEngine deutlich schneller.

Derzeit wird einmal pro Monat mit /root/bin/backup_host ein dump(8) (Level 0, Blockgröße 512 KiByte, Kompression mit bzip2) des Root-Filesystems vom Mail- / WWW- / LPRng- / …-Servers auf die NFS-Partition /temp durchgeführt. Zum restore muß dann eben die Platte mit einem der gängigen CD-Linuxe (zB http://www.grml.org/) oder dem NFS-Root von FullyAutomaticInstallation partitioniert, formatiert und zurück kopiert werden:

mkfs.ext3 -m 5 -c /dev/hda1
mkdir /mnt/disk; mount -t ext3 /dev/hda1 /mnt/disk
mkdir /mnt/temp; mount -t nfs faepsv03:/itp/faepsv03/temp /mnt/temp
cd /mnt/disk
restore rf /mnt/temp/dump/....
  • hostdump.sh
    • alle Linux und Unix-Varianten
    • braucht lauffähiges und installiertes System fürs Backup
    • muß installiert werden
    • braucht installiertes dump und restore
    • kein Windows-Backup
    • kann keine CD-Sets erzeugen
  • Partition Image
    • läuft auch von Knoppix und grml
    • NTFS Unterstützung “experimentell”
    • kein direktes Brennen des Images auf CD oder DVD
    • alt, kein Update seit 2001
    • Verwende ich nur für Windows
      • booten mit GRML
      • partimage -s faepsv04.tu-graz.ac.at -U <USER> -P <passwd> save /dev/sda1 $(hostname -s)-$(date -I)
      • bringt etwa 160 MiByte pro Minute
  • Mondo-Mindi
    • braucht lauffähiges und installiertes Linux fürs Backup
    • muß installiert werden
    • NTFS-Partitionen werde als große Datei betrachtet, kein Vorteil gegenüber dd
  • mkCDrec
    • braucht lauffähiges und installiertes Linux fürs Backup
    • muß installiert werden
    • kann zusätzlich als Minimal- und Reparatursystem verwendet werden
    • kein Backup von NTFS-Partitionen
  • Acronis True Image
    • kommerziell (zwar mir 50,– recht billig, aber halt doch mit Lizenzproblemen belastet)
    • schwer an Spezialfälle anzupassen
    • vermutlich problemloses Backup und Restore
  • bootcd
    • bestens an Debian angepasst :)
  • System Imager ist eigentlich als Installationstool gedacht, kann aber sicher auch für ein bare metal backup verwendet werden.
  • dd / cat / gzip / bzip2
    • braucht wesentlich mehr Platz als notwendig, weil auch leere Blöcke gesichert werden, Komprimierung ist langwierig
    • Partitionstabelle wird ganz zwanglos mitgesichert
    • ev. brauchbar für ganz neue PCs mit wenig fragmentierter Festplatte, die schwer wieder hergestellt werden können (z.B. Laptops unter MicrosoftWindows)
# backup
bzip2 -c -k -v /dev/sda | ssh ahi@faepsv04 cat ">" /backup/Images/$(hostname)-sda-$(date -I).bz2
# restore
ssh ahi@faepsv04.tu-graz.ac.at cat /backup/Images/test_image.bz2 | bzip2 -d > /dev/sda
  • Image For Windows
    • kann nicht auf einen UNIX File Server schreiben
    • sichert nur Windows-PCs
  • ntfsclone
    • kann nicht direkt auf einen File-Server schreiben, aber mit einer Pipe ins ssh …
dd if=/dev/sda bs=4096 count=256            | bzip2 -c | ssh ahi@faepsv04 cat ">" /backup/Images/$(hostname)-sda-mbr-$(date -I).bz2
ntfsclone --save-image --output - /dev/sda1 | bzip2 -c | ssh ahi@faepsv04 cat ">" /backup/Images/$(hostname)-sda1-ntfsclone-$(date -I).bz2
  • partclone
    • compiliert nicht out of the box, wenn man keine ReiserFS, XFS … braucht und die Pakete für lib…-dev nicht installiert
partclone.ntfs --clone -d --source /dev/sda1  | bzip2 -c | ssh ahi@faepsv04 cat ">" /backup/Images/$(hostname)-sda1-partclone-$(date -I).bz2'
  • Clonezilla und drbl (Diskless Remote Boot in Linux)
    • Eigentlich eine Lösung zum Clonen, kann aber auch zum Backup verwenden.
    • Verwendet partclone, partimage oder ntfsclone.
    • Nach dem Clonen eines Windows-Computers kann man mit http://www.drbl-winroll.org/ Hostname, SID, usw. setzen.

Privates Daten-Backup - neu und meist noch nicht genauer angesehen

Obnam

Ich verwende das im Testbetrieb zur Zeit zuhause - es funktioniert gut und spart durch Deduplizierung deutlich Platz bei digitalen Fotos, die von mehreren Accounts geteilt werden.

Leider: The summary is if you use Obnam you should switch to another backup program in the coming months.

Allerdings bleibt (vermutlich beim Runterfahren des Rechners) gelegentlich ein Lock übrig, der manuell gelöscht werden muß:

if pgrep -u root obnam; then
  echo "#### 'obnam' already running, bail out ####"
  exit 1
else
  # For use on a single computer we are reasonable sure there is no running 
  # obnam on this machine. So just break a lock if there is one.
  obnam force-lock
fi
obnam backup /home/
obnam forget --keep=4h,14d,9w,12m,30y
obnam generations

verschlüsseltes Backup

Der Benutzer root startet über cron das Backup und verwendet dabei seinen public key; der zugehörige private key muß ohne Passphrase seoin, ´um während des Backups Verwaltungsdaten auch lesen zu können. Ein Key ohne Passphrase sollte aber auf keinen Fall den Rechner verlassen - andererseits bedeutet ein fehlender Schlüssel im Fall eines Geräteschadens ein Desaster. Als mögliche Abhilfe bietet sich an, das Backup zusätzlich mit dem public key eines vernünftig geschützten Keypaares zu verschlüsseln. Ich verwende

den Schlüssel von root auf der sichernden Maschine
Der Schlüssel hat keine Passphrase, daher kann die Backuproutine unbeaufsichtigt laufen und trotzdem die Metadaten alter Sicherungsläufe lesen. Der Schlüssel selbst wird nicht gesichert und verlässt die entsprechende Maschine nicht.
meinen privaten Schlüssel mit Passphrase
Mit diesem Schlüssel kann ich auch auf anderen Maschinen das Backup mounten und gegebenenfalls auch die Daten wiederherstellen.
MNT=$(mktemp -d /tmp/mnt.XXXXXX)
obnam --client-name=ahi600 mount --to ${MNT}
ls -l ${MNT}/latest/
fusermount -u ${MNT}

Offene Punkte:

Alten privaten Schlüssel entfernen und neuen Schlüssel zufügen:

obnam list-keys
obnam list-toplevels
obnam --repository=... --client-name=.... --keyid 0x2DB8935D2FEFD5FA  add-key
#bnam --repository=... --client-name=.... --keid ....                 remove-key

Das funktioniert nicht - komischerweise ist der angemeckerte Key genau der Key, den ich eigentlich loswerden möchte (DSA 1024bit):

ERROR: R0C79EX: gpg failed with exit code 2
Command: gpg -q --batch --no-textmode -e --trust-model always --no-encrypt-to --no-default-recipient -r 87EEB9C85236161E -r A73CA4AD73AFD4A6 -r 2DB8935D2FEFD5FA
gpg: A73CA4AD73AFD4A6: skipped: Unbrauchbarer öffentlicher Schlüssel
gpg: [stdin]: encryption failed: Unbrauchbarer öffentlicher Schlüssel

Restic

Das wird vermutlich mein Ersatz für Obnam werden.

export RESTIC_REPOSITORY=/tmp/backup
export RESTIC_PASSWORD=abc   # ja, genau das ist es
restic init
restic backup ~/notebook/; sleep 1200
restic backup ~/notebook/; sleep 1200
restic backup ~/notebook/
restic snapshots
restic --help
restic help
restic backup ~/notebook/ ~/public_html/
restic snapshots
rm -rf $RESTIC_REPOSITORY

# und jetzt ernsthaft
BACKUP_SRV=lagerhaus
BACKUP_USR=backup
ssh-copy-id ${BACKUP_USR}@${BACKUP_SRV}

export RESTIC_REPOSITORY=sftp:${BACKUP_USR}@${BACKUP_SRV}:/srv/backup-restic
export RESTIC_PASSWORD=.................
restic init
restic /root
restic /root /etc /home
restic check

# und später automatisch
restic /root /etc /home
restic forget --keep-daily 14 --keep-weekly 6 --keep-monthly 9 --keep-yearly 30
restic prune
restic snapshots

Weitere Informationen

Author: Andreas Hirczy

Created: 2018-01-26 Fri 13:44

Validate XHTML 1.0