[Eisfair] backup-zip 1.0.40

Marcus Roeckrath marcus.roeckrath at gmx.de
Mo Aug 10 14:52:03 CEST 2015


Hallo Uwe,

Uwe Kunze wrote:

>> week=$(expr $(date +%U) % 2)
>> bekommst Du in $week entweder 0 oder 1.
>> Nur so als Idee.
> 
> Ja, an sowas hab ich auch schon gedacht.
> Es gibt ja mehrere "Bastelvarianten" .... mit einem eigenen Mount pro
> Backup-Job wärs eben "eleganter" ;-)

Vierzehntägig ginge auch damit nicht, weil es der cronjob nicht hergibt.

Wie gesagt, ich muss mir das in Ruhe ansehen, weil das bisherige Konzept so
gestaltet ist, dass alle definierten Mounts eingebunden werden egal ob sie
für die abzuarbeitenden Backup-Jobs notwendig sind oder nicht.

Das erfordert eine komplette Umstellung im Code, dessen Nebeneffekte erstmal
analysiert werden müssen.

> Ich habe als Bastellösung einfach zwei (unterschiedliche, von Hand
> editierte) config-Dateien (/etc/config.d/backip-zip1 und
> /etc/config.d/backup-zip2), die ich per cronjob jeweils austausche.
> Keine besonders "nachhaltige" Lösung, aber schnell gemacht ;-)
> 
>> Wie machst Du das bislang mit dem Hin- und Herschieben der von backup-zip
>> erzeugten Archive?
> 
> Ich hoffe, dass Backup-Zip SO funktioniert, wie ich mir das denke ;-)

Ja, ich hatte Dich zunächst so verstanden, dass auf Platte 1 gesichert wird
und Du dann die ungerade Backups auf eine zweite Platte verschiebst; das
könnte kritisch sein, wenn die Backup-Kette nicht fortlaufend nummeriert
ist.

> Backup-Zip prüft doch (vermutlich !) das letzte vorliegende Archiv auf
> Unterschiede zum aktuellen Auftrag (ich vermute das, weil ich nirgendwo
> ein "log-File" gefunden habe, wo Backup-Zip den Stand der archivierten
> Dateien protokolliert hätte) .... insofern hoffe ich, dass es keine
> Rolle spielt, ob das Archiv schon 14 Tage alt ist und ein jüngeres
> Archiv (auf der anderen Platte) gemacht wurde.

Ich verwende mit Backup-Zip nur tar-Archive und habe deshalb mit der
Abeitsweise unter rsync keine Erfahrungen.

-- 
Gruss Marcus


Mehr Informationen über die Mailingliste Eisfair