ADMIN 03/14 stellt Erste-Hilfe-Tipps zu Windows-Rettung, Backup und Recovery bei Datenbanken vor und verrät wie man Linux-Systeme vollständig sichert und ... (mehr)

Einfaches Setup

Im Großen und Ganzen dreht sich die gesamte Konfiguration nur um zwei wesentliche Parameter: »OUTPUT=« legt die bevorzugte Boot-Methode fest und »BACKUP=« die gewünschte Backup-Strategie. Mit »OUTPUT=USB« beispielsweise sorgt der Systemverwalter dafür, dass ReaR den Rescue-Kernel und die Rescue-Initrd auf das angegebene USB-Medium schreibt und dort den Bootloader entsprechend konfiguriert.

Alternativen für die anderen skizzierten Szenarien wären beispielsweise »OUTPUT=ISO« , »OUTPUT=PXE« oder »OUTPUT=RAMDISK« .

Mit »OUTPUT=RAMDISK« gibt ReaR nur den Kernel und die Initramfs aus, der Admin kümmert sich um die weitere Verarbeitung. In der Default-Einstellung legt ReaR das fertige ISO-Image in einer Datei unter »/var/lib/rear/output« ab, wofür »OUTPUT_URL=file://« verantwortlich ist.

Generell versucht ReaR je nach verwendeter Backup-Strategie das Bootmedium auch im Backup mit abzulegen. Bei TSM wird zum Beispiel das Bootmedium durch einen Aufruf der Backup-Software mit in die Sicherung übernommen. Verwendet der Admin das per Default auf Tar eingestellte Backup-Verfahren in Verbindung mit dem Parameter »BACKUP_URL« zum Angeben des Backup-Targets (zum Beispiel ein NFS-Share), landet das ISO-Image also automatisch auch dort (Abbildung 2).

Abbildung 2: Das ISO-Image landet im Normalfall auch im Backup.

Hier ist es wesentlich besser aufgehoben, denn »/var/lib/rear/output« würde im Ernstfall nicht mehr nur Verfügung stehen. Abweichend von diesem Verhalten, lässt sich mit »OUTPUT_URL=« aber auch ein anderes Ziel für das Image angeben. Zur Wahl stehen etwa »fish« , »ftp(s)« , »http(s)« , »rsync« und »sshfs« .

Die Backup-Strategie gibt »BACKUP=« an, wobei ReaR mit »BACKUP=NETFS« automatisch Tar benutzt. Mit »BACKUP_PROG_CRYPT_ENABLED=1« klappt das auch verschlüsselt. Eine Alternative zu Tar ohne Einsatz eines externen Backup-Programms ist beispielsweise »BACKUP=RSYNC« . Alternativ legt »BACKUP=REQUESTRESTORE« fest, dass ReaR nicht automatisch ein Backup anfertigt, sondern den Nutzer danach fragt. Ebenso lässt sich mit »BACKUP=EXTERNAL« eine individuelle Backup-Strategie einbeziehen.

Backup auf NFS oder CIFS

Wurde das Backup-Verfahren auf »NETFS« gesetzt, gibt »BACKUP_URL=« das gewünschte Backup-Ziel an, zum Beispiel ein USB-Device oder eine NFS- beziehungsweise CIFS-Freigabe:

BACKUP_URL=nfs://NFS-Server/Freigabe/Pfad ...

ReaR legt dann unterhalb von »NFS-Server/Freigabe/Pfad« einen Ordner mit dem Namen des Clients an. Es funktioniert aber auch eine Datei auf der lokalen Festplatte, ein Tape-Device oder eine Samba-Freigabe:

BACKUP_URL=file:///Verzeichnis/Pfad/
BACKUP_URL=tape:///dev/nst0, ...
BACKUP_URL=cifs://Samba-Server/Freigabe/Pfad..

Soll ReaR sich per CIFS/Samba authentifizieren, legt der Admin eine entsprechende Datei »/etc/rear/.cifs_credentials« an, auf die er aus »/etc/rear/local.conf« mit

BACKUP_OPTIONS="cred=/etc/rear/.cifs_credentials"

verweist und darin Werte für »username« , »password« und »domain« einträgt.

Wer »OUTPUT=USB« mit »BACKUP_URL=usb://...« kombiniert, kann sowohl das Backup als auch das Rescue-Image auf das gleiche USB-Device schreiben, was für den Ad-hoc-Einsatz sehr nützlich ist, weil man in einem Rutsch ein bootfähiges Wiederherstellungsmedium erhält, vorausgesetzt, es steht genügend Platz zur Verfügung:

BACKUP_URL=usb:///dev/Gerät/Label/REAR-000

ReaR legt per Default ein Voll-Backup an. Alternativ stehen eine Reihe von »EXCLUDE« -Optionen zum Eingrenzen des gewünschten Backup-Umfangs zur Verfügung. So lassen sich beispielsweise mit

AUTOEXCLUDE_PATH=( /media )

gezielt gemountete Verzeichnisse, wie etwa Netzwerkfreigaben oder gemountete externe Partitionen, vom Backup ausnehmen. Dagegen schließt

AUTOEXCLUDE_DISKS=y

sämtliche Festplatten und Partitionen vom Backup aus, die nicht von gemounteten Dateisystemen in Anspruch genommen werden. Genauso einfach lassen sich mit

AUTOEXCLUDE_AUTOFS=..

sämtliche Automounter-Pfade ausschließen.

Wer zunächst nur das Rescue-Image anlegen und testen will, startet ReaR dann mit »rear mkrescue« . Genauso ist es möglich, nur das Backup mit »rear mkbackuponly« anzuschieben.

Im Normalfall wird der Administrator beides in einen Rutsch erledigen wollen, was auch der beschriebenen Kernfunktionalität von ReaR entspricht.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019