Wieso steht eigentlich im Wiki-Artikel

Dies eignet sich nicht für umfassende Sicherungen des gesamten Systems oder aller persönlichen Daten, aber es ist gut, um ständig Zwischenstände der laufenden Arbeit zu sichern.

???

Das kann ich absolut nicht bestätigen! Ich nutze rsnapshot seit Jahren für meine (fast) täglichen Backups und habe bei minimalem Speicherverbrauch ständig mehrere vollständige Sätz meiner jeweils gesicherten Dateien verfügbar. Dadurch bleiben einem die erheblichen Nachteile einer inkrementellen Sicherung wie bei sbackup erspart: Man muss nicht erst raten, wann eine gesuchte Datei zuletzt gesichert wurde und kann auf das zeitaufwändige Entpacken verzichten.

Sollte der Satz nicht besser gestrichen werden?

Hallo,

keine Ahnung. Sofern sich kein (weitere) rsnapshot-Experte meldet könntest du über den Versionsverlauf versuchen herauszufinden, wer den Satz in den Artikel geschrieben hat und dann den Autor ggf. per PN dazu einladen, hier mit zu diskutieren.

Gruß, noisefloor

Würde ich ja gerne machen, aber mit der Verfasserangabe "ip-74-21.travedsl.de" kann ich leider nicht viel anfangen...

Wäre es unfein, das einfach selbst zu ändern?

Ich denke mal gemeint ist, dass rsnapshot kein Image auf Partitionsebene anlegt. Gibt ja Leute die sowas total toll finden und irgendwie als einzig wahre Backupstrategie verehren.

Hmmm, mag ja sein, aber das steht nicht da. Außerdem können das andere Programme - z.B. sbackup - auch nicht und werden trotzdem für regelmäßige Backups empfohlen.

Im Artikel wird hier empfohlen, die Anacronjobs mit den Standardverzeichnissen /etc/cron.daily, /etc/cron.weekly und /etc/cron.monthly zu definieren. User im Forum sind dieser Anleitung auch gefolgt (vgl. 2580418).

Meineserachtens sollte man das aber stattdessen direkt in der Anacrontab machen. Den Grund kann man bei Debian nachlesen (etwas knapper auch in man rsnapshot):

rsnapshot will work better if monthly is done before weekly, weekly before daily and daily before hourly.

For example, if you run "rsnapshot daily" then "rsnapshot weekly", then you will end up with no daily.6 snapshot, and a snapshot will be unnecessarily deleted (assuming the default rsnapshot.conf).

The daily will delete the old daily.6, rotate the daily snapshots up and promote hourly.5 to daily.0; then the weekly will delete weekly.3, rotate the weekly snapshots up and promote daily.6 to weekly.0. If rsnapshots are run in the other order, then daily.6 won't be deleted (because it will instead have been promoted to weekly.0).

Bei Verwendung der Standardverzeichnisse /etc/cron.* ist die Reihenfolge der Ausführung daily, weekly, monthly. Bei Einträgen in der Anacrontab kann man die Verzögerung und damit die Reihenfolge selbst festlegen, oder habe ich da einen Denkfehler drin?

Eine Anmerkung zum Einleitung des Artikels. Dort heißt es:

Ein Vorteil von rsnapshot, das wiederum auf rsync basiert, ist, dass die unveränderten Dateien und Verzeichnisse nur ein mal gesichert werden. In allen weiteren Snapshots wird lediglich ein Hardlink auf die vorhandene Datei gesetzt. Das kostet fast keinen Platz und erlaubt viele Sicherungen ohne entsprechenden Platzverbrauch. Auch wenn viele Snapshot-Ordner erstellt wurden, belegt jede Datei, solange sie nicht geändert wurde, nur ein mal Plattenplatz.

Im Artikel zu Back in Time steht zu demselben Sicherungsprinzip folgender Hinweis:

Beim Einsatz von Back in Time sollte man beachten, dass bei einer veränderten Datei immer der ganze zu sichernde Pfad komplett neu gesichert wird und Sicherungen so viel Platz in Anspruch nehmen können.

Ich hielte es für sinnvoll, den Hinweis von BiT auch auf rsnapshot zu übertragen.

Hab einen etwas exotischeren Informationsschnippsel ausgegraben: In Versionen bis 1.3.1 (zur Zeit aktuell) dürfen Pfade in /etc/rsnapshot.conf keine Leerzeichen enthalten. Um Verzeichnisse mit Leerzeichen im Pfad dennoch sichern zu können, muss man das Leerzeichen mit einem Fragezeichen ersetzen. Quelle: http://sourceforge.net/mailarchive/message.php?msg_id=23891237

Das Problem ist nur temporär und wird in 1.3.2 gefixed. Leider ist aber der Release von 1.3.2 seit 2009 geplant und immer noch nicht draußen. Daher vielleicht doch was fürs Wiki. Weiß bloß nicht so recht, wohin damit.

Danke für den Hinweis, hab es unter Problemhebung eingefügt.