rsync per ssh einer QNAP-NAS von Ubuntu-Server aus

Habe jetz mal ein bischen mit rsync herumprobiert (habe im Ubuntu-Wiki nachgesehen). Habe mir dazu den Befehl erstmal in Notepad gespeichert und editieren den dort, bevor ich den Befehle dann in das Terminalfenster vom Unbuntuserver kopiere. Diese weiße Schrift auf schwarzem Untergrund im Terminalfenster ist extrem schwer zu lesen und daher verliere ich dort immer total die Übersicht.

Also ich habe mal versucht, eine Versionierung hinzubekommen:
Code: 
rsync --delete -avbe 'ssh  -i /home/<User>/.ssh/qnap_rsa' admin@<IP>:/share/CACHEDEV1_DATA/Public/ /mnt/Backup1/Test-Backup2/Public/ --backup-dir=../old-Public

Funktioniert im Pinzip auch, nur leider wird nur die letzte vorherige Version behalten und gelöschte Dateien und Verzeichnisse bleiben wohl auf ewig im old-Public-Verzeichnis vorhanden.
Das ist aber nicht das was mir vorschwebt. Sondern ich wollte eigentlich sowas wie bei Acronis, d.h. täglich ein incrementelles Backup und wöchentlich ein Vollbackup, die Backups die älter als z.B. 2 Monate sind, werden dann von Acronis automatisch gelöscht. So kann ich auf die verschiedenen Versionen einer Datei 2 Monate lang zugreifen (in dieser Zeit würde ich hoffentlich merken, ob ich mir einen Verschlüsselungstrojaner eingefangen habe ;)) und bei gelöschten Dateien habe ich dann auch innerhalb dieser 2 Monate Zeit, eine der Versionen wiederherzustellen. Anhand des Backup-Datums kann ich die richtige Version finden. Alles was älter ist, wird gelöscht (braucht man dann ja nicht mehr). So müllt man sich nicht im Laufe der Zeit zu.
Geht das mit rsync nicht? Habe im Ubuntu-Wiki jedenfalls keinen Schalter hierzu entdeckt und die Anleitung dort schien mir sehr ausführlich zu sein (oder habe ich das übersehen?).
 
Wenn ich das so lese: @Tommes Hast Du nicht mal in Deiner Freizeit Lust die SmartBackupStrategy von raspiBackup in BasicBackup zu uebernehmen 😉
 
@framp
Ähm… naja… ich befürchte fast, das ich da sehr viel Freie Zeit für investieren muss. Aber ich schreib das mal auf meine Liste mit Dingen, die ich mal ausprobieren wollte. Die Liste mit Dingen, die ich noch erledigen wollte ist aktuell leider schon voll. Ich schau es mir auf jeden Fall mal an.
 
Der TE hat erwähnt dass er gerne ein grandfather-father-son Backup hätte. Mit BasicBackup könnte er das hinbekommen und ich habe @Tommes nur darauf hingewiesen wie er es mit möglichst geringem Aufwand in BasicBackup einbauen kann damit der TE das nutzen kann. Was ist da OT :unsure:
 
framp schrieb:
mit möglichst geringem Aufwand in BasicBackup einbauen kann damit der TE das nutzen kann. Was ist da OT :unsure:
Zum Vergrößern anklicken....

So ziemlich alles, aufgrund zweier Tatsachen:

1) BasicBackup ist für Synology-NAS programmiert
2) Der TE nutzt QNAP (somit nicht kompatibel mit dem Syno-Paket), als auch Ubuntu (ebenfalls nicht kompatibel mit dem Syno-Paket)

Denke, damit hat sich jegliche Diskussion darüber "hier in diesem Thread" erledigt... Ihr könnt euer Gespräch darüber aber gerne im z.B. BasicBackup-Thread (wo es vermutlich am besten aufgehoben wäre), oder einem anderen passenderen Thread fortführen. Von daher auch: "back2topic", danke.
 
@framp
Ich ziehe meinen Hut vor Leuten wie dir, die mir anbieten ihr geistiges Eigentum zu teilen um es z.B. in mein Prokjekt implementieren zu dürfen. Vielen Dank dafür.

Tommes
 
Zuletzt bearbeitet von einem Moderator:
Nordlicht000 schrieb:
Sondern ich wollte eigentlich sowas wie bei Acronis, d.h. täglich ein incrementelles Backup und wöchentlich ein Vollbackup, die Backups die älter als z.B. 2 Monate sind, werden dann von Acronis automatisch gelöscht. [...] Geht das mit rsync nicht?
Zum Vergrößern anklicken....
Rsync alleine kann das nicht. Dazu bedarf es eines, teils umfangreichen Scriptes, welches man i.d.R. nicht von der Stange kaufen kann.
 
Tommes schrieb:
Rsync alleine kann das nicht. Dazu bedarf es eines, teils umfangreichen Scriptes, welches man i.d.R. nicht von der Stange kaufen kann.
Zum Vergrößern anklicken....
ich denke mit nicht allzu grossem Aufwand kann man in etwa das hinbekommen was sich der TE vorstellt:

rsnapshot ist fuer Deltabackups in ein Tool welches wohl der Vorstellung des TEs in etwa entspricht. Dann noch per crontab in gewissen Abstaenden ein kleines nicht allzu umfangreiches Script aufrufen welches per cp das letzte Deltabackup ohne Option -l woanders hinkopiert und wenn eine gewisse Anzahl von Vollbackups ueberschritten ist das aelteste Vollbackup loescht.
 
Hardlinking kann rsync selbst... (--link-dest) und löschen... mein Gott, da mache ich dann irgendwann ein rm -Rf auf die alten Backups.
 
Barungar schrieb:
Hardlinking kann rsync selbst
Zum Vergrößern anklicken....
(y) Klar.

Aber das Suchen des Verzeichnisses welches bei --link-dest genutzt wird sowie das Suchen des Verzeichnisses fuer rm -Rf macht rsync nicht. Das zu Scripten ist auch kein grosser Akt. Das Versionierungshalten von taeglichen, woechentlichen monatlichen und jaehrlichen Backups kann man auch selbst schreiben. Ist allerdings schon etwas mehr dafuer zu tun ...

Mein Hinweis auf rsnapshot hilft dem TE Zeit zum Codieren und Testen zu sparen. Nur Vollbackups kann rsnapshot nicht erstellen und das kann man wirklich sehr schnell mit ein paar Codezeilen hinbekommen.
 
Du hast natuerlich Recht und Dein Einwand ist berechtigt. Aber es ist noch ein Unterschied ob Du ein tar Backup hast was alle Daten enthaelt und ein Vollbackup ist oder einen rsync Vollbackup der Hardlinks nutzt.

Wenn irgendwelche Dateien aus aelteren Backups die per Hardlink von neueren Backups genutzt werden korrupt werden ist der neuere Backup und u.U. auch viele vorherige Backups auch korrupt. Mit einer Kopie ohne Hardlinks hast Du einen von anderen vorherigen Backups unabhaengigen Backup der einem tar Vollbackup entspricht. Aber vielleicht meinte der TE das auch nicht unter dem Begriff Vollbackup. Dann wuerde rsnapshot sicherlich fuer ihn reichen.
 
framp schrieb:
Wenn irgendwelche Dateien aus aelteren Backups die per Hardlink von neueren Backups genutzt werden korrupt werden ist der neuere Backup und u.U. auch viele vorherige Backups auch korrupt.
Zum Vergrößern anklicken....
Na das stelle ich mir nicht einfach vor. Man müsste die Originaldatei finden und deren Inhalt ändern.
Das so etwas möglich ist, kann ich mir vorstellen, ist aber aufwendig.
Den Vorteil eines tar-Backups mit folgenden inkrementellen Backups sehe ich nicht.
Wenn das full-Backup korrupt ist, wird man mit den inkrementellen Backups keine Freude haben.
Ich sehe eher Vorteile, sollte ein tar-full-Backup gelöscht werden, hast du ein Problem.
Löschet man ein rsnapshot-Backup bleiben die nicht geänderten Daten erhalten.
 
Zuletzt bearbeitet:
frosch2 schrieb:
Na das stelle ich mir nicht einfach vor. Man müsste die Originaldatei finden und deren Inhalt ändern.
Zum Vergrößern anklicken....
Es muss nur der Sektor auf dem sich die Datei befindet unreadable werden.
frosch2 schrieb:
Den Vorteil eines tar-Backups mit folgenden inkrementellen Backups sehe ich nicht.
Zum Vergrößern anklicken....
Das war auch nicht mein Vorschlag. Es war nur dazu gedacht um den Unterschied des Begriffs "Vollbackup" bei tar und rsync mit Hardlinks deutlich zu machen.

frosch2 schrieb:
Löschet man ein rsnapshot-Backup bleiben die nicht geänderten Daten erhalten.
Zum Vergrößern anklicken....
Das liegt an den Hardlinks die genutzt werden.

Vielleicht habe ich mich etwas ungenau ausgedrueckt: Ein rsync Backup ist ein Delta Backup wenn Hardlinks genutzt werden. Es ist aber ein quasi Vollbackup weil ueber die Hardlinks saemtliche Dateien zur Verfuegung stehen. Aber eben nur quasi - da wenn irgendwelche Dateien die per Hardlink referenziert werden entweder manuell geaendert werden oder durch Plattenprobleme nicht mehr zugreifbar werden zerstoeren den quasi Vollbackup. Deshalb mein Vorschlag per cp ohne Hardlinks eine Kopie eines Backups als "richtigen" Fullbackup zu erstellen.

Aber vielleicht definiert der TE mal was er genau unter einem Fullbackup versteht und wozu er ihn haben moechte 😉
 
framp schrieb:
Wenn irgendwelche Dateien aus aelteren Backups die per Hardlink von neueren Backups genutzt werden korrupt werden ist der neuere Backup und u.U. auch viele vorherige Backups auch korrupt.
Zum Vergrößern anklicken....

Daher arbeitet Basic Backup in diesem Fall z.B. so…
Zitat aus der Basic Backup Hilfe:
Während des ersten, initialen Vollbackups werden sämtliche Daten aus den Quellordnern, im Ordner /Hauptversion gespeichert. Nach Beendigung dieses Vorganges wird mittels Hardlinks (cp -al) ein Abbild des Ordners /Hauptversion in den Ordner /Versionsverlauf gelegt, benannt nach Datum und Uhrzeit der aktuellen Datensicherung.

Bei allen nachfolgenden Datensicherungen werden nun die Quelldaten mit den Daten des Ordners /Hauptversion verglichen, welcher den aktuellen Stand der letzten Datensicherung enthält. Zwischenzeitlich neu erstellte oder geänderte Daten werden dabei dem Datensatz hinzugefügt, zwischenzeitlich gelöschte Daten werden aus dem Datensatz entfernt. Nach Beendigung dieses Vorganges wird erneut mittels Hardlinks ein Abbild des Ordners /Hauptversion in den Ordner /Versionsverlauf gelegt, wieder benannt nach Datum und Uhrzeit der aktuellen Datensicherung.
Zum Vergrößern anklicken....

So verhindere ich den Effekt, den du oben beschrieben hast. Über eine Ordnersuche mittels find kann man dann das Vorhalten der Versionen begrenzen, indem man einfach die Versionsstände, die älter als X Tage sind, löscht.
 
Zuletzt bearbeitet:
Vollbackup, Incrementelles Backup usw. Tja viele Begriffe, schwiedig zu beschreiben.
Also ich kenne das von Acronis so und das hat sich bei mir als sehr praktisch erwiesen:
Ich stelle Acronis auf "Incrementell" ein, aber das erste Backup ist natürlich automatisch immer ein Vollbackup und bei den folgenden Backups werden nur diejenigen Dateien ins Backup aufgenommen, die geändert wurden. Dann kann ich dort noch einstellen, nach wievielen Incrementellen Backups wieder ein Vollbackub gemacht werden soll und ich kann einstellen, wie lange eine Versionskette (also das Vollbackup mit den zugehörigen nachfolgenden Inkrementellen Backups) behalten werden soll oder alternativ auch wieviele Versionsketten behalten werden sollen. Ein Incrementelles Backup alleine nützt ja nichts, da dort nur die geänderten Dateien vorhanden sind. Für den vollständigen Restore, wenn man ein Incrementelles Backup zur Wiederherstellung auswählt, braucht es natürlich den zu dieser Versionskette gehörendes Vollbackup, aber das macht Acronis automatisch.

Ich habe mal ein bischen gegoogelt und hiernach wäre ja rsnapshot in etwas das was Acronis auch macht. Was vor allem ja wichtig ist, daß man beim Restore die richtigen Dateien mit der richtigen Version auch ohne lange Suche leicht findet und das scheint ja aufgrund der von rsnapshot erstellten Verzeichnissstruktur der Fall zu sein (jedes Backup im eigenen Verzeichnis und alle Dateien darüber erreichbar) im Gegensatz zu rdiff-backup. Vor allem braucht man dafür kein kompliziertes Kommandozeilen-Restore, sondern kann das direkt über einen Filemanager machen.
Habe mir die Anleitung im Ubuntu-Wiki auch mal durchgelesen, was ich da aber noch nicht verstehe: Wenn das allererste Backup (muß ja zwangsläufig ein Vollbackup sein, denn wohin sonst sollten die Harlinks gehen) gelöscht wird, dann gehen die Hardlinks noch ins Leere? Einen Mechnaismus, wo man angeben kann, nach wievielen Inkrementellen Backups wieder ein Vollbackup gemacht werden soll (z.B. alle 2 Wochen ein Vollbackup und dann täglich ein Inkrementelles Backup und Löschen einer Versionskette nach z.B. 2 Monaten), habe ich in der Anleitung nicht gefunden. Nur wenn man in gewissen Abständen wieder ein Vollbackup macht, dann kann man doch ältere Backups (bzw. eine ältere Versionskette) löschen?
Und wie werden die Hardlinks bei geänderten Dateien gesetzt? Immer ausgehend vom Vollbackup oder ausgehend vom vorherigen Inkrementellen Backup?
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.

Zurzeit aktive Besucher

Gesamt: 145 (Mitglieder: 6, Gäste: 139)

Neueste Beiträge

Letzte Anleitungen

Statistik des Forums

Themen
5.910
Beiträge
57.715
Mitglieder
5.864
Neuestes Mitglied
hootersusa

Teilen

Zurück
Oben