< Überlegungen >        < zurück >

Der Raspberry Pi als Server - wie sichere ich sinnvoll seine Einstellungen und unsere Daten?

Das Problem

Einen wirksamen Schutz unserer Daten gegen Verlust oder Zerstörung in einem kleinen familiären Netzwerk mit einer Handvoll Anwender zu erreichen, deren Daten auf einem allen Anwendern zugänglichen zentralen Medium gespeichert sind.

Die angestrebte Lösung

Eine einfach zu bedienende und unaufwendige Datensicherung, die mit minimalem Arbeitseinsatz bei einem "Vorfall" trotzdem die Wiederherstellung unserer Daten sichert.

Die Zielsetzung dieses Artikels

Der Artikel richtet sich an Linux-Beginner und noch unerfahrene Heim-Netzwerk-Administratoren. Er beschreibt nicht nur ein Programm, sondern versucht einen komplexen Prozess zu erklären und darüber Anregungen zur Entwicklung eigener Lösungen zu geben, bei dem erst am Ende ein Programm steht. Hier geht es nicht um professionelle Anforderungen und Lösungen und nicht um den Einsatz professioneller Software und Hardware - was ich im privaten Einsatz allerdings auch nicht unbedingt als notwendig erachte. Der Schwerpunkt soll eine etwas umfassenderer Betrachtung von Hintergrundaspekten sein, die wiederum einem Einsteiger beim grundsätzlichen Bewerten und Einschätzen des Themas helfen kann. Artikel für Fachleute gibt's en masse, nur setzen diese halt allzu oft voraus, dass man selber bereits Fachmann ist. Man kann aber nicht "oben" einsteigen, man muss von "unten" beginnen zu verstehen. In diesem Teilbereich des Artikels geht es ausschließlich um das Programm ExtraBAK. Weitere Hintergrund-Informationen und etwas umfassendere und Erklärungen über das Was? Warum? Wie? können zusätzlich bei Interesse auf dieser zum Thema gehörenden <Konzeptseite> nachgelesen werden. Hier und auf dieser Seite soll's dann doch mehr zielgerichtet um den technischen Lösungsweg mit Hilfe des Programms gehen.

Das Anforderungsprofil

Mit der Zielsetzung auf Zuverlässigkeit und Aufwandsminimierung habe ich das Programm für folgende Aufgaben geschrieben:

- Weitestgehend automatisierte Sicherung von User-Daten und -Dateien, sowie von Konfigurationsdateien und Einstellungen der PCs

- Tägliches "Spiegeln" relevanter Verzeichnisse mit rsync auf ein zweites Speichermedium außerhalb des User-Zugriffs

- Erstellen von einfach zu handhabenden Backup-Archiven in überschaubarer Größe, mit übersichtlichem Inhalt und einfach verifizierbar

- Zyklisches Erstellen von partiellen oder selektiven Backups eines vorgegebenen Speichermediums mit tar auf ein zweites Speichermedium außerhalb des User-Zugriffs (in den Varianten rollierend oder überschreibend oder versionierend)

- Mit sicherer Verschlüsselung (AES256, RSA2048) bei Fremd-Speicherung eines Archivs das Archiv vor unberechtigtem Einblick zu schützen

- Übertragung einer verschlüsselten Archiv-Kopie als "Anti-Feuer-, Hochwasser- u. Blitzschlag-Backup" auf einen externen Speicher (Internet-Cloud, eigener Web-Space)

Die Sicherung von Multimedia-Dateien in der Größenordnung vieler Terrabyte ist nicht beachtet und dafür ist ExtraBAK auch nicht geeignet. Der Schwerpunkt des Programms liegt allein in der Bedeutung von "unsere Daten", zu denen ich fremd erstellte Multimedia-Dateien eindeutig nicht zähle - zumal diese auch jederzeit wiederbeschafft werden können. Für andere Anforderungen, wenn also auch große Datenmengen berücksichtigt werden sollen, gibt es andere Konzepte, bessere Lösungen.

Die Abhängigkeiten

ExtraBAK hat folgende Abhängigkeiten:

- Geschrieben und getestet für/auf Debian und Raspian

- tar und sync für die eigentlichen Backup-Prozesse

- md5sum, wenn Checksummen für die spätere Verifizierung eines Archivs berechnet werden sollen (z.B. nach Crypt,  Send, Receive, Decrypt)

- sendmail, wenn eine Info-Email gesendet werden soll (unterstützt werden postfix (MTA als Daemon) und msmtp (Non-Daemon, via Relayhost)

- gpg, wenn von einem erstellten Tarfile eine verschlüsselte Kopie erzeugt werden soll

- ftp , wenn die verschlüsselte Kopie via FTP-Client auf einen FTP-Server gesichert werden soll

Die Funktionen sendmail, gpg und ftp sind nicht unbedingt Bestandteil einer Standard-Installation mit Debian/Raspian und müssen ggf. manuell nachinstalliert werden. sendmail erfordert eine eigene Konfiguration, die mit einem klassischen MTA durchaus sehr anspruchsvoll sein kann. Siehe dazu auch <zusätzliche Hinweise> für eine einfachere alternative Konfiguration mit msmtp. ExtraBAK verwendet gpg entweder mit symmetrischer Verschlüsselung AES256 oder mit asymmetrischer Verschlüsselung RSA2048. Die Verschlüsselung mit RSA2048 erfordert die vorherige Anlegung eines Schlüsselpaares gemäß gnupg-Handbuch. Das Handling mit einem ftp-Client ist nach meinen Kenntnissen seit Jahren standardisiert und erfordert außer korrekten Zugangsdaten in den xtbak*.conf's keine besondere Konfiguration.

Die verwendeten Speichermedien

Das folgende Bild zeigt beispielhaft einen serverseitigen Hardware-Einsatz, aus dem abgeleitet werden kann, welche Daten und Dateien überhaupt gesichert werden sollen. Zum einen sind es alle Konfigurationsdateien des Server-Betriebssystems, dann die auf der SSD gespeicherten anwendereigenen bzw. durch Anwender angelegte persönlichen Dateien, und schließlich einige weitere explizit bestimmte Dateien/Verzeichnisse (z.B. unsere eigenen Fotos) auf der Harddisk1 im Verzeichnis MultiMedia.

 

Der Backup-Plan

Das hier beschriebene Backup-Konzept umfasst 3 automatisch ablaufende Teilprozesse, die alle mit dem gleichen Programm abgewickelt werden:

Teilprozess 1:

Täglich die Anwenderdaten der SSD 1:1 auf HD1 sichern.

Teilprozess 2:

Für die Anwenderdaten der SSD werden aus den 3 betroffenen Verzeichnisse an 12 Terminen monatlich rollierend jeweils 1 Archiv-Container auf HD2 erstellt. Die insgesamt 12 Archive überschreiben sich jeweils im neuen Zyklus. Gültigkeitsdauer einer Archiv-Version = 1 Monat.

Teilprozess 3:

Konfigurationseinstellungen des Servers in fortlaufenden Versionsarchiven sichern, die bei Bedarf oder zu hohem Alter manuell gelöscht werden.

Den Umfang der Datensicherung im Teilprozess 1 veranschaulicht das folgende Bild:

 

Die 3 auf der SSD vorhandenen primären Verzeichnisse für Anwender-Daten werden täglich automatisch und ohne manuelles Eingreifen 1:1 zur HD1 synchronisiert. Somit besteht immer ein erstes primäres Backup aller Anwenderdaten mit maximal 1 Tag Verlustrisiko einzelner Dateien bei einem Ausfall der SSD. Die Kopien-Verzeichnisse der HD1 sind den Anwendern nicht zugänglich.

Alle durch die Anwender dynamisch erstellten und sich im täglichen Gebrauch befindenden Dateien liegen also einmal täglich als 1:1-Kopie auf einem zweiten Speichermedium vor. Die Qualität der Kopie auf der Festplatte kann jederzeit einfach über einen Filecompare oder schlichtes stichprobenartiges Öffnen von Dateien überprüft werden. Diese Vorgehensweise hat den Vorteil, dass eine mögliche Ausfallzeit bei einem Ausfall der SSD absolut minimiert werden kann, in dem vorübergehend einfach die Mounts der fstab auf die HD1 versetzt werden.

Es erfolgt bei der täglichen Sicherung zunächst keine Löschung der Dateien auf HD1, die aktuell beim Programmlauf auf der SSD nicht mehr vorhanden sind. Der Daten-Umfang auf HD1 wird deshalb im Laufe des Monats im Vergleich zur SSD ansteigen. Um das nicht ins unendliche anwachsen zu lassen, wird in diesem Teilprozess der Datenbestand auf HD1 einmalig pro Monat bereinigt. Das bedeutet, aktuell dann nicht mehr auf der SSD vorhandene Dateien werden einmalig pro Monat auch auf der HD1 gelöscht. Die Bereinigung erfolgt jeweils im ersten Lauf des Monats.

Ja, das ist richtig... durch die einmalige Bereinigung des Bestandes auf HD1 besteht eine kleine Lücke, in der man Dateien durch Anwenderfehler oder Fahrlässigkeit tatsächlich auch endgültig verlieren kann. Da es sich allerdings nur um aktuelle Dateien handeln kann, und zwar nur der letzten Tage, wird es allerdings mit vertretbaren Aufwand möglich sein, eine solche Datei auch wieder manuell zu rekonstruieren. Handelt es sich um eine Datei, die schon länger bearbeitet wurde, so befindet sich sogar eine Version in einer der letzten Sicherungen aus dem Teilprozess 2 (siehe unten), denn durch diesen Prozess wurden ja die Archive 2, 3 und 4 erstellt, über die auch ein Zugriff auf ältere Dateien bis in den Vormonat hinein möglich ist. Ich vernachlässige dieses kleine Restrisiko im Bewusstsein, dass es existiert, aber ich erachte das als irrelevant für uns.

Aber natürlich gibt es auch für dieses Problem eine einfache Lösung, um sogar dieses Restrisiko komplett auszuschließen, und zwar den Sync-Lauf aus TP1 generell "incremental" durchzuführen und für die Jobs aus TP2 nicht die SSD als Quelle zu nehmen, sondern HD1. Für die Backups aus TP2 hat das durch den vorherigen Sync-Lauf keinen nachteiligen Effekt, es wurden ja unmittelbar zuvor alle Dateien von der SSD zur HD1 synchronisiert - die Archive sind lediglich etwas größer. Und weil beim Sync-Lauf generell "incremental" eingestellt ist, verfügt die HD1 also immer über einen "noch unbereinigten" Datenstand beim Backup-Lauf.

Neben den täglichen regulären Sync-Läufen (immer vor den Backups) braucht es nun nur noch einen einmaligen zusätzlichen Sync-Lauf im Monat, der nach einem Backup-Lauf im Modus "identical" läuft, um damit die auf der SSD gelöschten Dateien nun auch auf HD1 zu entfernen. Danach hat man dann genau 1 Monat Zeit, um eine verlorene Datei doch noch wieder aus einem Archiv zurückzuholen. Mit dieser einfachen Vorgehensweise wäre ein Datenverlust aus dieser oben beschriebenen Situation nicht mehr möglich... aber wie gesagt, mir ist das zu unwichtig.

Selbst wenn man derzeit auf Linux-Systemen kaum Meldungen über Ransomware (Erpressungstrojaner) findet, so gibt es trotzdem keine Garantie dafür, dass das auch dauerhaft so bleibt. Aus dem Grund halte ich es heute schon für angebracht, die für eine Wiederherstellung relevanten Daten zusätzlich noch auf eine zweite Festplatte zu sichern.

Den Umfang der Datensicherung in den Teilprozessen 2 und 3 veranschaulicht das folgende Bild:

 

Die Besonderheit dieser zweiten Festplatte ist, sie ist zwar angeschlossen, muss aber vor der Verwendung manuell mit root-Rechten gemountet werden. ExtraBAK kann diesen Mount vor Beginn der Backups durchführen (siehe dazu unten die Parameter), dazu ist es aber notwendig, dass ExtraBAK mit root-Rechten gestartet wird. Dabei ist anzumerken, dass ExtraBAK ohne root-Rechte vermutlich sowieso nicht vollständig alle Dateien sichern kann, weil eine normale UserID eben nicht die Rechte hat, umfassend alle Verzeichnisse zu lesen.

Auf dieser zweiten Platte sind die zur Sicherung relevanten Dateien auch nicht 1:1 gespeichert, sondern teilweise in rollierenden Archiven und teilweise als Folge-Archive im Sinne einer Versions-Historie. Zum Beispiel reicht es mir nicht, aus dem Teilprozess 3 nur ein aktuelles Backup der Server-Konfiguration zu haben, sondern ich will auch so etwas wie Rollback-Szenarien ermöglichen. Da meine Server-Backups immer nur 30-40 KB (!) groß sind, ist es erfreulicherweise keine Platzverschwendung, auch die älteren Milestone-Backups noch aufzubewahren, z.B. den Wechsel von Wheezy nach Jessie, oder von Jessie nach Stretch, oder bei einem Rechnerwechsel. Nach kleineren Änderungen am Server-Betriebssystem starte ich ein solches Backup direkt manuell, außerdem wird jeweils einmal im Monat ein Backup automatisch erstellt. Alle paar Monate lösche ich die älteren dieser Zwischenbackups und erst bei bzw. vor einer gravierenden Systemänderung wird das letzte dieser Zwischenbackups zu einem langfristig aufbewahrten Milestone-Backup. Mein Aufwand für diese Systembetreuung ist verschwindend gering, so gering, dass ich manchmal z.B. bei der Anpassung von Backup-Parametern vorher in die Doku meines eigenen Programms schauen muss... denn ich fummel eigentlich viel zu selten dran rum, als das das zur Gewohnheit werden kann. Aber genau so soll‘s ja auch sein.

Etwas anders als mit den Server-Konfigurations-Einstellungen praktiziert handhabe ich im Teilprozess 2 die Anwenderdaten, weil die ja sowieso schon einmal täglich aktuell 1:1 auf HD1 gesichert sind. Für diese Daten sind zusätzlich insgesamt 12 Cronjobs definiert, die an 12 Tagen jeweils einen Teilbereichs-Backup-Job erledigen. Ich habe mich wegen der durchaus kritischen Einordnung des Leistungsspektrums des PI‘s zu diesem Job-Splitting entschlossen. Damit ist gewährleistet, dass Backup-Jobs immer nur kurzzeitig laufen. Auf die Backup-Qualität bzw. auf die Backup-Aktualität hat das Job-Splitting überhaupt keinen Einfluss.

Von der SSD werden die folgenden Ordner jeder 4 mal im Monat automatisch in ein eigenes Archiv zur HD2 gesichert:       

Für das auf der SSD liegende Ursprungsverzeichnis /Home liegen also auf HD2 kontinuierlich 4 unterschiedlich alte Backup-Archive vor, durchnummeriert von 1 bis 4 - die sich jeden Monat automatisch durch die maschinelle Backup-Erstellung überschreiben. Das gleich gilt natürlich auch für die zwei weiteren Ordner /Mail und /Alle. An diesem Punkt noch einmal zur Erinnerung der Hinweis zum Umfang dieser Archive: Da es sich bei den in den Archiv-Versionen gesicherten Dateien ausschließlich um eigene und persönliche Dateien der Anwender handelt, für deren Erstellung die Anwender immer direkt oder indirekt selber verantwortlich sind, haben diesen Archive immer auch einen überschaubaren Umfang. Alles zusammen genommen beansprucht trotz intensiver Nutzung gerade mal 10 GB an privaten Daten (ohne die eigenen Foto-Archive). Bislang war es mir also noch immer völlig problemlos möglich, explizit ein Archiv auszuwählen, es einfach in einer RAM-Disk zu entpacken, um darüber dann Zugriff auf ganz bestimmte Dateien für die Wiederherstellung zu erlangen.

Wenn also tatsächlich einmal gleichzeitig SSD und HD1 irreparabel ausfallen würden, mit einem Totalverlust aller Daten, so bestehen auf der HD2 immer noch für die 3 wirklich wichtigen Daten-Verzeichnisse jeweils 4 Versionen mit jeweils einem vollständigen Datenstand, bei der die letzte Version maximal 1 Woche alt ist. Außerdem wird jeweils nach der Erstellung eines Archivs aus TP2 dieses letzte und aktuelle Archiv als "Anti-Blitzschlag-, Hochwasser- und Feuer-Archiv" unmittelbar verschlüsselt und via FTP auf den Web-Space übertragen. Somit ergibt sich folgender abgestufter Backup-Verlauf:

 

Und als letzten und ultimativen Beweis für meine Datenverlustparanoia erstelle ich manuell von der HD2 noch alle paar Wochen eine Kopie der dann gerade aktuellen BAK-Versionen auf eine via LUKS verschlüsselte 2"-HD, die in ein kleines Schließfach unserer Bank passt. Der klar umrissene Umfang an Dateien sowie die schon erstellten Backup-Archive und deren überschaubare Größe macht diese letzte Sicherung zu einer kurzen Fingerübung. Die ist zwar meistens zwischen 2 und 3 Monaten alt... OK, seis drum.... aber mit diesem Rest-Risiko kann ich wirklich gut leben. Im großen und ganzen kann man also schon feststellen, wo meine Prioritäten liegen.... und die liegen eindeutig bei den Daten, die ich bei Verlust entweder gar nicht oder nur mit unverhältnismäßig hohem Aufwand wiederherstellen kann. Ist ein solcher Aufwand übertrieben? Nun ja, diese Frage muss jeder für sich selber beantworten. Wie ich bereits ganz zu Anfang dieses Artikels festgestellt habe, entscheiden allein die Antworten auf die Fragen "Wie wichtig sind mir diese betroffenen Daten? Wie bewerte ich das voraussichtliche Schadensausmaß bei Verlust aller Daten?", welcher Aufwand übertrieben ist oder andersrum, welcher Aufwand zum Schutz der eigenen Daten vielleicht notwendig ist. Diese Antworten sind der einzige Indikator, an dem sich alle weiteren Schritte orientieren müssen. Aber wie alles im Leben relativ ist, so ist auch der bisher hier beschriebene Aufwand relativ. ExtraBAK wurde geschrieben, um eben allen Aufwand weitestgehend von mir fernzuhalten und alles notwendige autonom zu leisten - ohne weiteres Zutun von mir.

Die Implementierung

Für die für uns wirklich wichtigen Daten habe ich (nach meiner Vorstellung) eine eindeutige und strukturierte Grundlage auf den Speichermedien geschaffen, die es mir sowohl ermöglicht, zusammengehörende Dateigruppen auch zusammen (ohne jeweiligen vorherigen hohen Selektionsaufwand) automatisch in einem Abwasch zu sichern, als auch über überschaubare Archivdatei-Größen leicht handhabbare Sicherungspakete zu erhalten. Das letztere ist dann wichtig, wenn wirklich mal nach einem Crash eine Wiederherstellung notwendig ist. Den reinen Betriebssystem-Dateien hingegen widme ich heute überhaupt keine Aufmerksamkeit mehr.... wozu auch... die können ja jederzeit als ISO-File einfach aus dem Internet geladen und erneut installiert werden.

Grundlage dieser eindeutigen Struktur sind die 3 primären Datenverzeichnisse, für die die Synchronisierung und insgesamt 12 Backup-Jobs definiert sind.

1. Persönliche Anwender-Daten  (exklusive Eigentumsrechte eines User)

2. Allgemeine Anwender-Daten (allgemeine Rechte für alle User)

3. Mail-Server-Konten (dezidierte Zugangsrechte (zwar exklusive User-Rechte, aber kein willkürlicher Zugriff durch den User))

Den automatischen Ablauf aller Prozesse ermöglicht diese root-Crontab:

# Tägliches Backup geänderter Files von SSD nach HD1, um 4:00 Uhr

0 4  * * *        /usr/local/bin/xtbak -o Sync -v

# 1. Backup - Startzeit um 05:00 Uhr

# - am 1.,2. und 3. erster von 4 Zyklen mit jeweils 3 Tage Full-Bak's der Daten-Bereiche

# - am 4. Selectives Backup der ganzen SDC  

# - am 5. Explizites Backup der Serverkonfiguration  

0 5  1 * *        /usr/local/bin/xtbak -o Mail -s 1 -v

0 5  2 * *        /usr/local/bin/xtbak -o Home -s 1 -v

0 5  3 * *        /usr/local/bin/xtbak -o Alle -s 1 -v

0 5  4 * *        /usr/local/bin/xtbak -o SDC -v

0 5  5 * *        /usr/local/bin/xtbak -v

# 2. Backup

0 5  8 * *        /usr/local/bin/xtbak -o Mail -s 2 -v

0 5  9 * *        /usr/local/bin/xtbak -o Home -s 2 -v

0 5 10 * *        /usr/local/bin/xtbak -o Alle -s 2 -v

# 3. Backup

0 5 16 * *        /usr/local/bin/xtbak -o Mail -s 3 -v

0 5 17 * *        /usr/local/bin/xtbak -o Home -s 3 -v

0 5 18 * *        /usr/local/bin/xtbak -o Alle -s 3 -v

# 4. Backup

0 5 24 * *        /usr/local/bin/xtbak -o Mail -s 4 -v

0 5 25 * *        /usr/local/bin/xtbak -o Home -s 4 -v

0 5 26 * *        /usr/local/bin/xtbak -o Alle -s 4 -v

Die gleichbleibende Startzeit der Jobs um 5:00 Uhr ist einfach begründet. Das ist die letzte Stunde der Nacht, die definitiv noch außerhalb des Anwender-Zeitfensters eines normalen Tages liegt. Gleichzeitig ist 5:00 Uhr die Zeit, in der andere ab 23:00 Uhr beginnende Nachtzeit-Jobs definitiv abgeschlossen sind. Die Regeln für die eigene Planung muss natürlich jeder Admin selber festlegen. Selbst eine Crontab ist nicht zwingend notwendig, man kann's auch einfach manuell starten.

Das gesamte Sicherungskonzept wird also nur mit einem einzigen Programm erledigt. Das Programm ExtraBAK (xtbak) verwendet zur Erstellung der eigentlichen Backups die zwei Standard-Linux-Programme tar und rsync und zur Festlegung, was es in einem bestimmten Job tun soll, für diesen Job zusätzliche Steuer-Dateien. Die tatsächlich wichtige Eigenschaft des Programms ist es also, individuelle Einstellungen für einen bestimmten Job aus Konfigurationsdateien auszulesen und das Backup danach entsprechend durchzuführen.

Das Statement xtbak -o Mail -s 1 -v bedeutet: Führe die Sicherung für das Object 'Mail' durch, ergänze den Archiv-Namen mit dem Suffix 1 und schalte mit -v alle Job-Meldungen ab. Wie in der obigen Crontab ersichtlich, werden für das Objekt Mail auf gleiche Weise an 3 weiteren Terminen die folgenden Archive 2, 3 und 4 erzeugt, die sich von Monat zu Monat rollierend immer wieder überschreiben. Die verwendeten Steuerdateien sind für das Objekt Mail immer die gleichen, die notwendige Unterscheidung für 4 Archive wird mit den angefügten Suffixes 1-4 erreicht. Wenn man sich die Laufzeiten anschaut, kann man feststellen, dass das für einen RPi völlig unkritisch und geradezu zu vernachlässigen ist:

2017-11-01 05:05 Mail_1.tgz

2017-11-01 05:05 Mail_1.tgz.md5

2017-11-08 05:05 Mail_2.tgz

2017-11-08 05:05 Mail_2.tgz.md5

2017-10-16 05:05 Mail_3.tgz

2017-10-16 05:05 Mail_3.tgz.md5

2017-10-24 05:04 Mail_4.tgz

2017-10-24 05:05 Mail_4.tgz.md5

Rückblickend vom aktuellen Tag ausgehend bestehen also immer 4 unterschiedlich alte Archive.

Die tägliche Synchronisation der Anwenderdaten auf ein zweites Speichermedium im Teilprozess 1

Beginnen wir mit den Einstellungen für den Teil des Backup-Konzeptes, den ich zuvor als Teilprozess 1 bezeichnet habe und der auch in der Crontab mit xtbak -o Sync -v als erstes steht, und zwar die tägliche Synchronisation von der SSD zur HD1. Der Objectname ist Sync, und -v unterdrückt die hier unerwünschten Konsolenausgaben. Den Umfang und die Art der Synchronisation bestimmt die folgende ExtraBAK-Conf, die naturgemäß für den rsync-Job keine zusätzlichen List-Files benötigt, wie sie im TP2 erforderlich sind. Ich beschreibe jetzt hier nur die für den rsync-Lauf speziellen Parameter, die Erklärungen zu den anderen allgemein geltenden Parametern folgen weiter unten.

xtbak_Sync.conf

Description = Sync SSD to HD1 $HOSTNAME

# Mount = UUID=1234*5678 /media/HD1 ext4 rw,nosuid,nodev,noexec,noatime

  LogFile=/var/log/DailyLogs_SSDBAK/$DAY.log

  MailFrom = xtbak@raspi3

  MailTo = thomas@raspi3

# verbose = false

# simulation = true

  SyncType = incremental

# SyncType = identical

 sync = /media/SSD/Mail  > /media/HD1

 SyncIdenticAtDom = 00

 sync = /media/SSD/Home  > /media/HD1

 SyncIdenticAtDom = 02

 sync = /media/SSD/Daten > /media/HD1

 SyncIdenticAtDom = 03

In der Conf  muss (mindestens) 1 Sync-Auftrag eingetragen sein, es sind aber auch mehrere möglich - hier im Beispiel sind es 3 Aufträge, die jeweils mit "sync" beginnen. Das Zeichen > ist als Trennung und zur Unterscheidung zwischen Quelle und Ziel zwingend notwendig! Somit sollten auch Leerstellen in der gesamten Pfadangabe möglich sein. Das Verhalten bei Pfaden in Anführungszeichen "/Pfad/Datei Name" ist unbestimmt, deshalb empfehle ich keine Anführungszeichen bei vorhandenen Spaces zu verwenden. Die vollständigen Pfade werden vom Programm zwischen "=" und ">" sowie zwischen ">" und CR/LF ermittelt. Es ist auf jeden Fall völlig konfliktfrei, wenn auf Spaces in Pfaden verzichtet wird.

       Original:                                Kopie:

sync = /home/thomas/test/quelle/Mozilla       > /home/thomas/test/ziel

sync = /home/thomas/test/quelle/LibreOffice   > /home/thomas/test/ziel

SyncType ist eine Default-Einstellung für alle Jobs, wenn für die Aufträge keine individuellen Angaben über Sync identical at Day of Month (DOM) gegeben sind, mit den beiden erlaubten Einstellungen identical und incremental.

Synctype

SyncIdenticAtDom

Wenn SyncIdenticAtDom einmal verwendet wird, dann muss es generell für ALLE Aufträge gesetzt sein! Also, entweder gar nicht oder wie oben im Beispiel für jeden Sync-Auftrag.

Eine Besonderheit in der obigen Beispiel-Konfiguration ist die LogFile-Einstellung in ein extra dafür reserviertes Verzeichnis. Das enthält für jeden Tag des Monats ein Log, in dem genau nachverfolgt werden kann, welche Daten wie synchronisiert wurden. Mit jedem neuen Monat überschreiben sich ältere Logs vom Vormonat automatisch. Der Umfang aller 31 Logs beträgt nicht mal 1 MB, da es sich hier ausschließlich um einen Textreport für die Bewegung neuer und geänderter Dateien handelt.

Die Einstellungen zur Datensicherung im Teilprozess 2

Der in der Crontab mit dem "Objekt"-Parameter -o Mail übergebene Wert wird dazu verwendet, die drei zum eigentlichen Job zugehörigen Einstellungsdateien zu bestimmen und zu lesen. Die "conf" enthält die Kontroll-Parameter für den Job, "list" enthält die ins Backup einzuschließenden und "xlist" die auszuschließenden Dateien und Verzeichnisse. Damit ist gleichzeitig auch die Namenskonvention für diese 3 Dateien eindeutig beschrieben und festgelegt:

xtbak_Mail.conf

xtbak_Mail.list

xtbak_Mail.xlist

Weiterhin wird im Crontab als Suffix zur Bildung des Archivnamens der Parameter -s 1 im ersten Lauf übergeben, -s 2 im zweiten Lauf, usw. Dieser Parameter entspricht dem in der Conf eingetragenen Statement AddSuffix = 1. Der Unterschied ist, dass die Übergabe über -s bei jedem Programmlauf dynamisch änderbar ist, als Eintrag in der Conf ist der Wert jedoch statisch. Mit dieser Suffix-Parameter-Angabe werden also 4 Archive erzeugt,  quasi durchnummeriert von 1-4, von denen jedes 1 Monat gültig ist und die sich nach Ablauf des Monats automatisch überschreiben.

Der Inhalt der 3 Dateien ist einfach erklärt:

Description = SIK SSD-Mail ($HOSTNAME)

  TargetDirectory = /media/HD2/Backup

  Mount = UUID=1234509876 /media/HD2 ext4 rw,nosuid,nodev,noexec,noatime

  KeepLog = false

  MailFrom = xtbak@raspi3

  MailTo = thomas@raspi3

  md5Checksum = true

  TestTarfile = true

# ContentList = true

# Verbose = false

  GpgOutfile = /media/HD1/ftpup/mail.enc

  FtpSendFile = /media/HD1/ftpup/mail.enc

/media/SSD/Mail

.Trash*

Trash*

Papierkorb*

Junk*

*.msf

Nach gleichem Muster existieren die folgenden Dateien auch für die 2 weiteren benannten Sicherungs-Objekte, z.B.:

für das Sicherungs-Objekt "Home"

xtbak_Home.conf

xtbak_Home.list

xtbak_Home.xlist

für das Sicherungs-Objekt "Alle"

xtbak_Alle.conf

xtbak_Alle.list

xtbak_Alle.xlist

Die Einstellungen zur Sicherung von Konfiguration und Server-Einstellungen  im Teilprozess 3

Neben den benannten bzw. objektbezogenen Sicherungen gibt es dieses zusätzliche und unbenannte Default-Objekt. Dieses Objekt hat keine ausdrückliche Namenszuweisung, die damit schon eine Bestimmung beschreibt und insofern auch keine Bestimmung für eine besondere Sicherung. Ich verwende dieses Objekt zum einen für die Defaulteinstellungen, die von den anderen Objekt-Confs genutzt werden, sowie zur Sicherung von systemrelevanten Dateien (Konfigurations / Einstellungen) des PCs, auf dem es installiert ist.

xtbak.conf

xtbak.list

xtbak.xlist

Das Absicht war, ein primäres "Objekt" auf verschiedenen Rechnern zu haben, mit dem zwar wiederholt, aber nur einmalig ausgewählte eigene Dateien und Verzeichnisse gesichert werden können. Auf den Client-PCs gibt es nicht viel auszuwählen und ein aufwendiges Scheduling ist auch nicht zu hinterlegen, sondern es gilt einfach nur die Direktive "Jetzt sichern nach Einstellungen!", was mit der Anweisung xtbak -c erfolgt. Das -c ist nicht zwingend notwendig, zeigt aber vor dem manuell gestarteten Programmlauf eine Checkliste der gesetzten Parameter und verlangt eine Bestätigung, dass der Job starten soll. Das ist hilfreich beim Einstellen der jeweiligen *.conf. Ein automatischer Lauf ist natürlich auch möglich. In einem automatischen Job ist -c allerdings störend, da ist -v die richtige Einstellung, um alle Ausgaben zu unterdrücken.

Gleichzeitig enthält dieses unbenannte Objekt auch noch einige Default-Einstellungen, die für alle anderen Objekte verwendet werden können. Die Defaults beziehen sich ausschließlich auf Verzeichnis-Pfade, erkennbar am Namensbestandteil "Default". Am Ende der Einstellungen sind die GPG- und Ftp-Parameter teilweise gesetzt, lediglich GpgOutFile und FtpSendFile sind mit # kommentiert. Das bedeutet, das Archiv dieser Conf wird nicht verschlüsselt und übertragen, aber die Passphrase und die Zugangsdaten können für die Archive verwendet werden, in deren Conf  GpgOutFile und FtpSendFile gesetzt sind (siehe oben).

xtbak.conf                 (mit teilweise geltenden Default-Einstellungen für weitere Sicherungs-Objekte)

Description = SIK conf-files ($HOSTNAME)

  TargetDirectory = /media/HD2/Backup/ExtraBAK/$HOSTNAME

  TargetDefaultDirectory = /media/HD2/Backup/ExtraBAK

  TargetDefaultAltDirectory = /media/HD1/Downloads

  AddPrefix = RP3

# AddPrefix = $DAY_$MONTH_$YEAR_$DOY_Freetext

# AddSuffix = $USER_$HOSTNAME_Freetext

  AddDate = true

# AddHostname = true

# AddUsername = true

# AddBasename = true

# Mount = //172.10.100.2/{ShareName}   /media/{ShareName}   cifs  credentials={CredentialsName},uid=1000,gid=1000,rw

  Mount = UUID=5678*1234 /media/HD2 ext4 rw,nosuid,nodev,noexec,noatime

# PathLog = /var/log

  PathLogDefault = /tmp

# LogFile=

  KeepLog = false

# MailFrom = xtbak@raspi3

# MailTo = thomas@raspi3

# md5Checksum=true

  TestTarfile=true

# ContentList=true

# Verbose=false

  GpgPassPhrase = 1234

# GpgKeyID = TomsSecureKey

# GpgOutFile= /media/ftpup/rp3.enc

  FtpHost = www.toml.de

  FtpUser = toml

  FtpPwd = toms_secret_password

  FtpPath = Backups

# FtpSendFile = /media/ftpup/rp3.enc

Die Sicherung von Konfigurationseinstellungen eines PCs/Servers (hier ein bestimmter Server) beschränke ich auf diese Dateien und Verzeichnisse. Grundlage für Einstellungen ist die oben stehende xtbak.conf. Verschlüsselung und Übertragung des Archivs findet in diesem Beispiel nicht statt.

xtbak.list       

/etc

/usr/local/bin

/var/spool/cron/crontabs

/home

/root

xtbak.xlist

/etc/alternatives

/etc/sane.d

/etc/ssl/certs

/etc/dbus-1

/etc/dkms

/etc/fonts

/etc/console-setup

/etc/ufw

.Trash*

Trash*

/home/*/Daten

Die Größe des erstellten Backups umfasst gerade mal 500 KB, weniger als 1/2 MB.  Und mit diesem kleinen Backup habe ich alle Grundlagen, um einen neuen Server wieder so einzurichten, dass er die gleiche Funktionalität wie zuvor der alte hat. Um das noch mal deutlich zu sagen: Ich lege keinen Wert darauf, einen alten Server wiederzubeleben. Die Unsicherheit, dass ich mit einer vielleicht zweifelhaften Wiederherstellung aus einem toten Server möglicherweise einen Zombie gemacht habe, ist mir bei meinem Kenntnisstand schlichtweg zu groß. Ich halte es für unsere Zwecke für die bessere Idee, einfach ein neues aktuelles OS einzurichten und damit gleichzeitig auch noch in der Vergangenheit sich vielleicht anhäufende Dateileichen zu beseitigen.

Die Parameter zur Steuerung der Jobs

Bis auf die Parameter mit dem Namensteil "Default" können alle Parameter auch in die individuellen objektbezogenen Conf-Dateien eingetragen werden. Für nicht angegebene Parameter gelten die Default-Einstellungen des Programms und nicht die Werte, die in der xtbak.conf eingetragen sind. Die in xtbak.conf eingetragenen Parameter werden nur im Job ohne übergebenen Objekt-Name (-o) verwendet.

Für alle Job-Läufe gilt: Ist ein Zielverzeichnis angegeben und es existiert, dann verwende es. Ist kein Zielverzeichnis angegeben oder es existiert nicht, dann verwende das Default-Zielverzeichnis aus der unbenannten (!) xtbak.conf. Ist kein Default-Zielverzeichnis angegeben oder es existiert nicht, dann verwende das alternative Default-Zielverzeichnis. Wenn auch das nicht existiert, wird das Programm beendet. Sofern in einer Objektbezogenen Conf auch Default-Verzeichnisse definiert sind, werden diese nicht berücksichtigt. Alle anderen Statements werden je Objekt auch nur dann berücksichtigt, wenn sie als Parameter in der Objekt-Conf definiert sind.

Bezogen auf die Beispiele ergeben sich also folgende Speicherorte:

Man muss sich also schon zuvor einige Gedanken machen, welche Backups wohin gespeichert werden. Startet man die Jobs immer nur manuell und nur mit Verwendung des immer gleichen Backup-Mediums, ist das natürlich einfach, dann reicht für alle Confs ein einziger Eintrag in der xtbak.conf zur Festlegung von TargetDefaultDirectory. Wenn es jedoch auch um automatische Abläufe geht, sollte man ggf. ein Fallback-Szenario einplanen, falls die Backup-Platte aus irgendeinem Grund nicht erreicht werden kann. Bei mir werden die Daten dann dort gespeichert, wo ich zwangsläufig unmittelbar drüber stolpere.

Wie man in der obigen Beispiel-Conf sieht, sind mehrere Parameter mit # kommentiert. Der Grund ist ganz einfach: Ich aktiviere für einen bestimmten Job nur die Parameter, die auch tatsächlich verwendet werden sollen. Wenn ich nicht möchte, dass der Hostname des Computers zum Archivnamen hinzugefügt werden soll, dann aktiviere ich diesen Parameter nicht. Wenn ich jedoch z.B. auf verschiedenen PC's überall automatisch die Favoritenliste des Browsers sichern will, dann benötige ich den Hostnamen zur Unterscheidung der Backups - also entferne ich # oder ich verwende individuell die Variabel $HOSTNAME.

Die beiden Parameter Mailto und Mailfrom sind Teil eines Controllings, also der Bestätigung, dass die Jobs auch wirklich im Ergebnis das erbringen, was von ihnen ihnen erwartet wird. Mit den beiden Mail-Parametern erfolgt eine Benachrichtigung per Email darüber, dass ein geplanter Job auch tatsächlich gestartet ist und erfolgreich bis zum Ende gelaufen ist.

Beispiele für den Inhalt der EMails, wenn alle bzw. mehrere Aufgaben eingeplant sind:

Mailfrom enthält den Absender der EMail. Ich habe in meinen Beispielen den Scriptnamen xtbak@raspi3 als Absender eingesetzt. Damit sehe ich auf einen Blick, welches Programm auf welcher Maschine die empfangene Mail gesendet hat. Das funktioniert aber nur deshalb, weil mein Mailserver diese Mail als lokale Mail behandelt, was wiederum bedeutet, dass die Mail gar nicht über das Internet versendet wurde, sie hat unser Netzwerk gar nicht verlassen.

Wenn allerdings eine reguläre Mail (z.B. mit msmtp) unter Einbeziehung des Smarthosts eines Email-Providers versendet werden soll, kann es sein, dass eine EMail als Spam verworfen wird, wenn der Absender wie hier in meinem Beispiel nicht einer gültigen FQDN-Adresse entspricht. Da gibt es aber keine Regel, die ISP handhaben das unterschiedlich und man muss das einfach von Fall zu Fall ausprobieren. Schlimmstenfalls trage ich einfach eine reguläre echte Absender-Adresse ein. Ist für Mailto ein Wert gesetzt, werden immer 2 Mails gesendet, einmal wenn der Job gestartet wurde, einmal nach erfolgreicher Beendigung.

Bezüglich dieser von mir gewünschten Benachrichtigung per Email habe ich auf der Konzeptseite noch einige <zusätzliche Hinweise> angefügt. Denn insbesondere die Benachrichtigung per Email kann durchaus ein äußerst anspruchsvolles Unterfangen sein, siehe mein Projekt Mailserver. Ich hoffe, dass mir mit den Ergänzungshinweisen eine leicht umzusetzende Alternative gelungen ist.

Ja, es stimmt... die Passphrase zum Verschlüsseln steht tatsächlich in Reinschrift in einer Conf. Ja und? Was solls? Ich unterstelle einfach, dass mein Server nicht kompromittiert ist und dort, wo es steht, hat kein Anwender eine Lese-Erlaubnis. Und wenn er wirklich kompromittiert wäre, schert mich die geklaute Passphrase auch nicht, weil dann der ungebetene Gast sowieso Zugriff auf die unverschlüsselten Daten hat. Aber wie gesagt, hätte ich Zweifel an der Integrität meiner Server-Installation, würde ich jetzt sofort ein komplett neues und damit sauberes Linux-Image installieren. Danach hätte ich dann wieder kein Problem damit, die Passphrase erneut in der Conf zu speichern. Wegen des Umstands, dass es hier keine Kommunikationswege für den Austausch von Schlüsseln gibt, die Schlüssel also nie transportiert werden müssen, dass das OS des Servers für mich zweifelsfrei integer ist, und das dem Server kein unbeschränkter ausgehender Traffic ins Internet erlaubt ist, stellt diese Lösung meiner Meinung  nach auch für mich kein Risiko dar. Wem das nicht gefällt, der kann den Weg der asymmetrischen Verschlüsselung mit RSA2048 wählen. ExtraBAK unterstützt beides. Wobei man aber dann die aktuellen Hinweise im WWW im Auge behalten sollte, ob RSA2048 weiterhin als sicher gilt - was es derzeit natürlich ist.

Der beste Weg zum Verstehen aller Parameter ist hier, einfach mit den Einstellungen zu experimentieren und den Job jeweils mit dem Checkparameter -c zu starten und nach der Parameter-Kontrolle wieder abzubrechen. Man erkennt, wie das Programm die Einstellungen gelesen hat und was am Ende dabei rauskommen würde.  Ein gefahrlos verwendbares Verzeichnis-Test-Szenario ohne wichtige Daten ist im Tarfile des Programm-Downloads enthalten.

Ein Beispiel für eine spezielle Sicherung der Mailserver-Konfiguration

Als letztes hier noch ein aktuelles und spezielles Beispiel, welches ausschließlich zur Sicherung der Mailserver-Einstellungen gedacht ist:

xtbak_Mailserver.conf

Description = SIK Mailsystem-Confs $HOSTNAME

TargetDirectory = /media/HD2/Backup/ExtraBAK

addprefix = RP3

adddate = true

Mount = UUID=5678*1234 /media/HD2 ext4 rw,nosuid,nodev,noexec,noatime

KeepLog = false

xtbak_Mailserver .list

/etc/postfix

/etc/dovecot

/etc/radicale

/etc/hosts

/etc/hostname

/etc/fstab

/etc/mailname

/etc/environment

/etc/aliases

/etc/systemd/system/getmail-eventhandler-prepare.service

/etc/systemd/system/getmail-eventhandler.service

/etc/systemd/system/radicale-prepare.service

/etc/systemd/system/radicale.service

/etc/systemd/system/set-iptables.service

/usr/local/bin/getmail-eventhandler

/usr/local/bin/xtbak_Mailserver.conf

/usr/local/bin/xtbak_Mailserver.list

/usr/local/bin/xtbak_Mailserver.xlist

/home

/media/SSD/Mail/Getmail

/media/SSD/Mail/Sieve

xtbak_Mailserver .xlist

.cache

.config

Daten

log

.local

.ne

.ssh

oldmail-*

*.log

.Trash*

Trash*

Das erzeugte wirklich kleine 80KB-Archiv enthält alle relevanten Konfigurationseinstellungen zur Einrichtung eines neuen Mailservers nach der Installation eines neuen Linux-Images. Da muss man nicht suchen und es kann auch nichts vergessen werden - alles liegt vollständig und zusammen an einem Ort vor. Hier ist es als Versionierungs-Update eingestellt, was derzeit bei mir im Laufe der Zeit zur Erstellung folgender Archive geführt hat, wovon einige heute rückwirkend betrachtet Milestone-Archive sind:

RP3_Mailserver_170508_Initial.tgz

RP3_Mailserver_170607_NewISP.tgz

RP3_Mailserver_170624_Raspberry_PI_2.tgz

RP3_Mailserver_170627_Maildrop.tgz

RP3_Mailserver_170707 Procmail.tgz

RP3_Mailserver_171022 Jessie.tgz

RP3_Mailserver_171030_Baikal.tgz

RP3_Mailserver_171105.tgz

RP3_Mailserver_171107.tgz

RP3_Mailserver_171111.tgz

Aktuell wurde Jessie durch Stretch ersetzt und Baikal durch Radicale.

Also doch ein Fullbackup der SD-Card?

Wer sich aufmerksam das weiter oben stehende Crontab-Beispiel angesehen hat, wird vielleicht bemerkt haben, dass auch die SDC einmal monatlich automatisch komplett gesichert wird, und das obwohl ich doch zuvor eine Rechnung aufgemacht habe, wie wenig sinnvoll das doch ist. Ein Widerspruch? Nicht unbedingt. Hinter diesem Backup steckt nämlich absolut nicht die Absicht, es wieder restoren zu können. Das interessiert mich tatsächlich überhaupt nicht. Hierbei geht es mir einzig und allein darum, ein für ein paar Monate gültiges Nachschlagewerk zu haben. Wann brauche ich das? Zum Beispiel dann, wenn ich bei einer Neuinstallation meines Servers (Wheezy > Jessie > Stretch) rückwirkend Zusammenhänge oder Abhängigkeiten nachsehen oder vergleichen will, gesetzte Rechte, spezielle Speicherorte, usw. Oder um nach im Internet gefundenen Hinweisen zu irgendeinem Thema vergleichen zu können "Wie ist es jetzt bei mir, war das schon immer so?". Hin und wieder schaue ich (mehr oder weniger willkürlich/zufällig) auf meine Backup-Verzeichnisse und wenn ich sehe, dass da was aufgelaufen ist, lösche ich einfach alle Sicherungen, die älter als 6 Monate sind.

xtbak_SDC.conf

Description = SIK Full-SDC $HOSTNAME

targetdirectory = /media/HD2/Backup/ExtraBAK-SDC

mount = Mount = UUID=5678*1234 /media/HD2 ext4 rw,nosuid,nodev,noexec,noatime

adddate = true

addprefix = RP3

Verbose = false

MailFrom = xtbak@raspi3

MailTo = thomas@raspi3

KeepLog = false

xtbak_ SDC .list

/

xtbak_ SDC .xlist

.Trash*

Trash*

lost+found

/dev

/home/*/Daten

/media

/mnt

/proc

/sys

/tmp

/var/log

Zu den beiden List-Files ist hier nicht viel zu erklären... natürlich beginnt das Backup mit dem Root-Verzeichnis "/". Aber ich will auch nur tatsächlich wichtiges speichern, deshalb filtert die XList alle unbenötigten Dateien und Verzeichnisse wieder aus. Mit diesen Einstellungen enthält das Backup der SDC alles, was für's Nachlesen wichtig ist, jedoch u.a. keinerlei User-Daten oder -Dateien. Und es behält bei mir trotzdem eine überschaubare Größe von nur 570 MB.

Als Vorgehensweise beim Einrichten der beiden List-Files für ein neues Sicherungs-Objekt empfehle ich, zuerst nur die Include-List einzurichten. Das heißt, zuerst wird nur der zu sichernde Umfang festgelegt, die auszuschließenden Dateien folgen später. Man kann auch direkt die XList verwenden, aber da empfiehlt es sich, wie im folgenden Beispiel nur mit unkritischen Einträge anzufangen:  xtbak_MeinObjekt .xlist .Trash* Trash* Wenn die Include-List steht, würde ich den Job einmal laufen lassen und schauen, was tatsächlich im Archiv ankommt. Ich beobachte in dem Fall immer den Job-Lauf und das neue Archiv in einem 2. Terminalfenster. Ich möchte schließlich sehen, falls wegen eines meiner Fehler auf einmal auch die 6-TB-Platte gesichert wird, obwohl nur ein kleines besonderes Datenverzeichnis enthalten sein sollte..... dann breche ich den Job natürlich sofort ab. Außerdem sehe ich auch sofort, dass das neue Archiv unmöglich 80 MB groß sein kann, wenn der zu sichernde Umfang nur 2 MB beträgt ... also auch hier "Abbruch". Enthält das Archiv dann die gewünschten Dateien und Verzeichnisse, überprüfe ich, ob auch verzichtbares enthalten ist. Sind es da nur kleine Einzeldateien, ist mir das egal, handelt es sich zum Beispiel jedoch um ein .Cache-Dir mit 100'en von Temp-Files oder um Einzeldateien in GB-Größe, entferne ich dieses Verzeichnis oder die Datei über die XList. Beim nächsten Lauf sollten diese Dateien dann nicht mehr enthalten sein. Zur Kontrolle eines fertig erstellten Tarfiles empfehle ich direkt im Terminalfenster den Midnight-Commander zu verwenden. Aufgrund der eher geringen Größe meiner Backups ist das immer völlig unproblematisch.

Haftungsausschluss

Das von mir geschriebene Programm ExtraBAK (Scriptname = xtbak) ist als Bash-Script nur ein Wrapper für die Linux-Programme tar, rsync, gpg und ftp. Das bedeutet, ExtraBAK erstellt selber keine Backups und hat auch keine eigenen Verschlüsselungs-Algorithmen oder Übertragungsprotokolle implementiert, sondern verwendet zur Erstellung von Archiven oder Datei-Kopien die Programme tar und rsync, sowie gpg zum Verschlüsseln und ftp zum Senden.

Ich erhebe keinen Anspruch darauf, dass ExtraBAK vollständig fehlerfrei programmiert ist und ich behaupte das auch nicht. Sowohl durch Programmierfehler in den 3 Programmen (ExtraBAK, tar und rsync) ist Datenverlust möglich, wie auch durch den Anwender selber verursacht durch unsachgemäße oder fehlerhafte Einstellungen oder falsche Parameterübergaben bei den Programmen. Darüber hinaus ruft ExtraBAK zum Verschlüsseln des Archivs und zum anschließenden Senden via ftp-client weitere Fremdprogramme auf, zu deren Fehlerfreiheit ich ebenfalls keine Aussagen treffen kann. Eine fehlerhafte Verschlüsselung, leicht zu erratende Passphrasen oder ein manipulierter Sendevorgang ermöglichen deshalb vielleicht einen unberechtigten Zugriff durch Dritte auf die Archive.  Deshalb schließe ich jede Haftung für Schäden an Software oder Hardware oder Vermögensschäden oder für Datenverlust aus, die durch die Benutzung des Programms ExtraBAK enstehen. Die Benutzung des Programms erfolgt auf eigenes Risiko.

Das klingt beunruhigender als es wirklich ist, denn ich nutze das Programm für alle meine Backups seit längerem ohne jegliche Probleme. Allerdings überprüfe ich selber auch regelmäßig sowohl die Erstellung als auch die Qualität der Backups und auch der verschlüsselten extern gespeicherten Backups. Außerdem bin ich äußerst gewissenhaft bei den Einstellungen und aktivieren einen Job endgültig erst dann, wenn ich sicher bin, dass er ausgetestet ist und wie geplant funktioniert.

Änderungsprotokoll       

< zurück >        < Überlegungen >