überschriebene Daten. alte version retten? [erl.]

[mclien]

EDIT:
Problem existierte quasi doch gar nicht. Alle Daten waren da. In dem Sinne ist dann keine Lösung, falls Du hier nach einer Datenrettung für den Fall suchst, Sorry
/EDIT, es folg der orig. Post:
Also ich bin nicht ganz sicher, ob ich es verbockt habe, aber wir vermissen gerade ein Version einer Datei.
Passiert ist das ganze wahrscheinlich bei dem Umzug der Datene auf einen anderen Server. Habe alle backups und alten Platten durchgesehen, nix zu finden. Das einzige was ich mir vorstellen kann ist folgendes:
1. Datenstand von alt zu neu mit rsync übertragen
2. am client den den nfs mount von alt zu neu geändert
3. client ändert die datei und schreibt auf den neuen Server zurück
4. fälschlicherweise wird nochmal von alt zu neu gesynct -> die neue datei wird mit der alten Version überschrieben
( was ja aber bei Verwendung von rsync -avu nicht passieren dürfte)
Die Frage also: Ist gibt es irgendeine chance an die überschriebene Verison zu kommen?

[Natureshadow]

Nö.

Und für die Zukunft: http://git-annex.branchable.com

-nik

[mclien]

nunja, was wirklich konstruktives hatte ich auch nicht wirklich erwartet, als ich den Nik erblickte.
Wie dem auch sei. Problem hat sich selbst gelöst.
Wie von mir richtig angenommen konnte der beschriebene Fehler bei der Verwendung von rsync mit der Option "-u --update" nicht passiert sein. Auch eine gewisse Versionierung ist mit den passenden rsync Optionen möglich. In der verwendung zusätzlicher tools sehe ich eher fehler- als Lösungsquellen.

[mclien]

mit rsync ist es eigentlich nur ein Frage der Backupzyklen und -medien.
Angestrebtes Ziel bei mir (sobald ich mir die Platten und andere Hardware leisten kann): innerhalb des Netzes rsync vom Server auf einen Rechner im Netz per cron 1-2 Mal täglich, oder je nach Sicherheitsbedürfnis auch öfter. Wöchentliche Sicherung auf externe Platte, die woanders als bei mir im Haus lagert.
Bei besonderen Ereignissen kann dann die externe Platte(n) auch zwischendurch benutzt werden.

[dufty]

Die NetApp-Filer hatten immer so schöne .hourly / .daily.
Btrfs soll das auch snapshots bekommen (oder schon haben?).

[mclien]

wo wir gerade bei rsync sind.
Mir ging gerade folgendes durch den Kopf (um etwas Plattenplatz zu sparen, bzw. nicht mehrfach redundat zu bevorraten):
wöchentliche Sicherung mache ich auf eine extrne festplatte, wie schon erwähnt.
Schick wäre jetzt eine tägliche Sicherung (auch mehrmals) auf eine Platte im lokalen Netz zu machen (extra Platte in einem client in kombinaltion mit cron bspw.). Allerding soll die nur die Differenz zu der letzten Wochensicherung speichern.
Bei der wöchentlichen Sicherung läuft dann zunächst der rsync auf den Produktivstand der Daten und im Anschluss wird die Differenzsicherung auf der täglich Platte gelöscht und der Zyklus startet neu.
Dazu müsste man allerdings die Liste des Datenstandes auf der ext. Platte irgendwie festhalten. Kan rsync das?

[Cae]

Dazu müsste man allerdings die Liste des Datenstandes auf der ext. Platte irgendwie festhalten. Kan rsync das?

Du kannst rsync Hardlinks verwenden lassen und mehrere damit vollstaendige Backupstaende ohne wesentlichen Platzverbrauch speichern. Die Option heisst --link-dest, ich verwende sie vereinfacht so:

Code: Alles auswählen

epochsec="$(date +%s)";
backupdir=/media/backup/{FQDN der Maschine};
backuplatest=latest;
backuplink=$backupdir/$backuplink;
mount /media/backup/;
/usr/bin/rsync -aHAXv --del / $backupdir/$epochsec/ \
	--numeric-ids           \
	--link-dest $backuplink \
	--exclude lost+found    \
	--exclude /media        \
	--exclude /dev          \
	--exclude /proc         \
	--exclude /sys;

oldpwd=$PWD; # somehow redundant
cd $backupdir
/bin/ln -nfs $epochsec $backuplatest;
cd $oldpwd;

umount /media/backup/;

(Ich hoffe mal, das nicht zu krass vereinfach zu haben. Mein Skript hat LVM mit Snapshots drin und ausfuehrliche Fehlerbehandlung.)

Das Prinzip: rsync legt fuer jeden Backupvorgang ein neues Verzeichnis (Name == Unix-Timestamp) an, welches rsync mit neuen/geaenderten Dateien befuellt. Identische Dateien werden in ein Verzeichnis latest gehardlinkt und fressen praktisch keinen Speicher. Anschliessend wird ein Symlink latest --> {timestamp} auf das gerade angelegte Verzeichnis gesetzt, damit im naechsten Durchlauf die Differenz auf die Vorgaenger-Version geht und nicht auf die vor-Vorgaenger-Version. Ausserdem ist's praktisch zum "Version von gestern Abend wiederherstellen".

Gruss Cae

[feltel]

Die Beiträge eines Störers wurden abgetrennt und ins Archiv verschoben. Daher bitte nicht wundern wenn manche Beitragsabfolgen logisch nicht konsistent erscheinen.