Abbildung 3: Die Restore-Oberfläche von Back in Time zeigt links die Snapshots, rechts deren Inhalte an.

Anders als Déjà Dup setzt Back in Time auf Cron, aber auch Anacron, um Jobs regelmäßig auszuführen, und kennt zudem Profile. Nach dem Start landet der User automatisch im »Hauptprofil« und klopft dort über Reiter die Details für den Backupprozess fest. Über die Einstellungen ergänzt er später weitere Profile.

In Sachen Zielorte für Backups bietet Back in Time eher Hausmannskost: Dateien legt der Admin lokal oder über SSH ab, immerhin wartet in beiden Fällen die Option, die Ladung zu verschlüsseln. Wer Samba nutzen möchte, muss tricksen: Über die »cifs-utils« und die »/etc/fstab« lassen sich Samba-Shares in jenen Rechner einhängen, auf dem die Backupsoftware läuft.

Wesentlich flexibler ist der Umgang mit Sicherungszeitpunkten (Abbildung 4): Die reichen von »Alle 5 Minuten« bis »Jeden Monat« . Notebook-Träger dürfte die Option »Täglich (anacron)« interessieren, auch an Nutzer externer Festplatten haben die Entwickler gedacht und sichern »sobald die Festplatte angeschlossen ist (udev)« . Zudem ist es möglich, »bei jedem Start/Neustart« zu sichern oder den Dienst zu »deaktivieren« .

Abbildung 4: Back in Time kennt zahlreiche Sicherungsintervalle. Es reagiert auch dann, wenn ein User einen USB-Stick einsteckt.

Die Inklusion und Exklusion von Dateien klappt wie gehabt, nur dass der Admin beim Ausschluss wahlweise reguläre Ausdrücke einsetzt.

Sehr fein abgestuft ist die Platzverwaltung. Per Default löscht Back in Time Sicherungen, die älter als zehn Jahre sind, oder wenn der Speicherplatz kleiner als 1 GByte wird beziehungsweise die freien Inodes auf einen Anteil von unter 2 Prozent fallen. Wer nicht stumpf alte Backups rasieren möchte, entscheidet sich für »intelligentes Löschen« und bestimmt selbst, nach welchem System die Software ihre Snapshots ausdünnt.

Schließlich warten in den Reitern »Optionen« und »Einstellungen für Experten« noch weiter gehende Möglichkeiten. So erzeugt Back in Time standardmäßig keine neuen Backups, wenn sich bei den Dateien nichts ändert. Das lässt sich auf Wunsch auch mit Prüfsummen entdecken. Back in Time protokolliert standardmäßig »alles« , bei Fehlern in den Snapshots fährt die Software dennoch mit ihrer Arbeit fort. Benachrichtigungen sind aktiviert. Experten stellen zudem die Priorität für den Cronjob ein, drosseln auf Wunsch die Rsync-Bandbreite und bewahren ACLs und erweiterte Attribute.

Wertung

Im Hintergrund von Back in Time erledigen alte Bekannte die Arbeit: wesentlich Rsync, »cp« und »diff« . Da das Programm für unveränderte Dateien Hardlinks verwendet, müssen lokale und entfernte Dateisysteme diese beherrschen. Außerdem schließt Back in Time Dateien mit vorangestelltem Punkt zunächst vom Backup aus. Auch eine Kompression fehlt, was bei größeren Datenmengen unangenehm auffällt.

Dafür ist Back in Time in einigen Belangen deutlich flexibler als Déjà Dup, vor allem wenn es um Backupintervalle und Snapshot-Verwaltung geht. Auch die Funktion zum Wiederherstellen arbeitet gut: Der Admin wählt eine Datei aus, klickt sie mit der rechten Maustaste an und wählt dann »Snapshots« aus. Nun erscheinen die bisherigen Revisionen der Datei mit Aufnahmedatum und Uhrzeit. Ein weiterer Rechtsklick auf den gewählten Kandidaten erlaubt es, den Inhalt der Datei mit dem einer anderen zu vergleichen oder sie wiederherzustellen.

Simple Backup

Zu den schwächeren Kandidaten im Test gehört Sbackup (Abbildung 5, [5]), eine Abkürzung für Simple Backup. Nicht nur warnt das Ubuntu-Wiki vor der Zuverlässigkeit der Software [14], auch die Aufteilung verwirrt ein wenig: Es gibt einen Backup-Daemon sowie zwei separate grafische Oberflächen. Eine dient zum Wiederherstellen, eine zum Konfigurieren. Zudem unterscheidet Sbackup zwischen normalen Usern und Root. Wer etwa Cron verwenden will, damit die Software regelmäßig Backups macht, muss die Konfigurationsoberfläche mit Rootrechten über »sudo sbackup-config-gtk« aufrufen. Andernfalls lässt sich die von Cron gewohnte flexible Zeitplanung nicht einrichten.