Es ist schon eine Weile her, das ich gefragt wurde warum ich rdiff-backup nutze. rsync gehe doch genauso gut.
Ja und Nein, und wir werden hier beides nutzen, sichern wir doch brav an zwei Orten.
Wie immer, auch Backup-lösungen gibt es viele und ich kann nur jedem empfehlen, sich seine „Beste“ selber auszutesten.
Zurück zu rsync, Ja es geht solange genauso gut, wie man für sich selber sichert. Spätestens, wenn man mehr Benutzer im Netz hat, und fleissige dazu, deren Daten man mit sichert, lernt man die Vorzüge von rdiff-backup schnell zu schätzen.
Nun aber rin in die Kartoffeln:

gateway: ~# apt install rdiff-backup rsync wie gesagt wir nutzen beides
und machen nicht lang rum, erstellen das erste Backup von unserem System auf /backup. Dabei verzichten ( –exclude ) wir als erstes auf /backup ( wir wollen ja keine „Schleife“ setzen ) und weitere, für ein Backup „unwichtige“ Verzeichnisse ( /var/log ist in diesem Kontext nur „unwichtig“, weil wir nicht „stündlich“ sichern ).
gateway: ~# rdiff-backup –force –exclude /backup  –exclude /var/lib  –exclude /var/log  –exclude /dev –exclude /proc –exclude /sys –exclude /run / /backup
das dauert ein bisschen….

Auch hier wieder ein Problem mit der Darstellung im Browser!
Vor force und exclude sind ZWEI Bindestriche! Im Bearbeitungsfenster sieht alles gut aus, im Browser nicht. Screenshot:

Syntax

rdiff-backup –force –exclude /[PFADwird-nicht-gesichert] /[PFADder-gesichert-wird] (hier / alles) /[PFADwo-wird-gesichert] (hier /backup)

man rdiff-backup

gateway: ~#l /backup zeigt uns nun ein „vollständig“ gesichertes System.

CRON

Während wir jetzt am System weiterarbeiten, können wir diese Sicherungen mehr oder weniger regelmäßig im Hintergrund laufen lassen.
Das dafür zuständige Programm ist cron, bearbeitet wird cron über die crontab.
Es gibt Systemcrons, wie in /etc/logrotate.d, aber auch jeder Benutzer kann eine eigene crontab erstellen.

crontab -e
öffnet den Editor für die crontab
crontab -l
zeigt uns die crontab

gateway: ~#crontab -e

no crontab for root - using an empty one
 

 Select an editor.  To change later, run 'select-editor'.
   1. /bin/nano        <---- easiest
   2. /usr/bin/vim.tiny
 

 Choose 1-2 [1]:[zeigt die Vorgabe] also ein einfaches enter wählt 1 aus...

####################################################
# For example, you can run a backup of all your user accounts
 # at 5 a.m every week with:
 # 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
 # Auch eine Variante....spart Platz
 # For more information see the manual pages of crontab(5) and cron(8)
 # 
 # m h  dom mon dow   command
#m=Minute h=Stunde dom=Tag des Monats mon=Monat dow=Tag der Woche Befehl
0 23 * * * rdiff-backup --force --exclude /backup  --exclude /var/lib  --exclude /var/log  --exclude /dev --exclude /proc --exclude /sys --exclude /run / /backup

würde also jeden Tag um 23Uhr ein neues Backup anlegen.
0 23 * * 1
würde jeden Montag um 23Uhr...
0 23 1 * *
würde jeden 1. jeden Monats...
0 23 1 1 *
würde jeden 1. Januar ...
speichern und schliessen aktiviert die crontab 

Das ist jetzt vielleicht etwas übertrieben und nur ein Beispiel. Ich mache Backups der Router nur vor einem Upgrade oder vor Wartungsarbeiten von Hand, werden dort schließlich keine Daten gespeichert. Das besagte /var/log ist da eher von Bedeutung im Falle eines Sicherheitsvorfalles. Für diesen Zweck sei aber auch eher das Schlagwort rsyslog ins Rennen geworfen…

Was jetzt aber bei rdiff-backup beim zweiten Durchlauf passiert, ist interessant.
rdiff legt Verzeichnisse rdiff-backup-data an und speichert zu allen Daten, die sich im Vergleich zum vorherigen Backup verändert haben, dort die alten Versionen gepackt in DatumUhrzeit.gz Dateien.
Im obersten Backupverzeichnis liegen so immer die letzten Versionen.
Zugegeben, das Wiederherstellen der alten Dateien könnte jetzt etwas komfortabler sein, zumal wenn man von Timemachine verwöhnt ist, aber es geht.

Ans Herz legen möchte ich in diesem Zusammenhang diese beiden Seiten,

–Backup unter Linux mit rdiff-backup
–Rdiff-backup Verzeichnisstruktur

Backups von frischen Konfigurationsdateien:

Im weiteren Verlauf kommen wir zu Standardkonfigurationsdateien von Diensten, die direkt nach dem Installieren lauffähig sind und sofort gestartet werden. Diese Dateien werden wir bearbeiten und an unsere Ansprüche anpassen.
Der brave Admin macht, bevor er an solchen Dateien rummacht, immer eine Kopie, z.B.

cp [NAME] [NAME.orig]

damit er, wenn er sich denn mal verlaufen hat in den tausend Möglichkeiten was falsch zu machen, immer zurückfindet zum Originalzustand, der eben lauffähig war.
Das vergisst man erfahrungsgemäss aber auch schonmal im Eifer des Gefechts.
Auch jetzt ist ein Backup echt gut und praktisch.

Wollen wir uns dazu vielleicht direkt ein „alias“ zu schreiben? Vielleicht backup?

Nun zum sichern des Backups an einem zweiten Ort, denn was nützt das schönste Backup, wenn es mit abfackelt?

Dazu nutzen wir rsync, ein prima Programm um ( remote-sync ) zwei Verzeichnisse auf zwei rechnern auf einen identischen Stand zu bringen.

Legen wir also zunächst ein Verzeichnis dafür auf unserem Verwaltungsrechner an:

ich@meinPC: ~ #mkdir backups backups/gateway
erstellt erst das Verzeichnis /home/ich/backups und dann /home/ich/backups/gateway
ich@meinPC: ~ #rsync ttist rsync schon auf dem Rechner?
wenn ja, kommt die Meldung rsync findet tt nicht, wenn nein, kommt die Meldung Befehl unbekannt und Du musst erstmal rsync deinem System konform installieren.

Dann steht einem sync von /backup auf gateway und backups/gateway auf meinPC aber nichts mehr im Wege. rsync bedient sich der Funktionalität von SSH und da wir mit unserem Schlüssel bereits bestens gerüstet sind, kann es sofort losgehen:

ich@meinPC: ~ #rsync -avz [email protected]:/backup/* ~/backups/gateway

Das dauert wieder, diesmal etwas länger.
Kaffee?
Oder mal mit

man rsync

schauen was die Optionen -avz zu bedeuten haben…
Wir sind gesichert!

Bevor wir das Kapitel abschliessen, schauen wir noch ganz kurz auf die andere Seite, scp (source-copy), eine weitere Funktion, die sich an SSH bedient.
scp hätte den ersten Durchgang unseres rsync Manövers ebenso erledigen können, den einfachen Kopiervorgang von Rechner A zu Rechner B.
Erst wenn schon Datensätze vorhanden sind, spielt rsync seine Stärke aus, und kopiert nun nur die Unterschiede. Das kann scp nicht.

Angenommen ich habe mich in der Datei beispiel.conf völlig verzettelt und möchte diese jetzt in der Version von letztem Monat wiederherstellen und habe die noch auf meinem Verwaltungsrechner im Backup.

ich@meinPC: ~ #scp ~/backups/gateway/etc/beispiel/beispiel.conf [email protected]:/etc/beispiel/
kopiert die gesicherte Datei direkt an den richtigen Ort

Erwähnen möchte ich der Vollständigkeithalber noch die Möglichkeit unter LVM mit Snapshots Sicherungen des Systems anzulegen.

next> LVM Snapshots