Remote Ordner sichern mit 5.2 nicht mehr möglich - Lösungen?

Status
Für weitere Antworten geschlossen.

elastico

Benutzer
Mitglied seit
31. Okt 2014
Beiträge
15
Punkte für Reaktionen
0
Punkte
0
Hallo,

(ich nutze eine DS1513+)

Bisher hatte ich Version 5.1 laufen. Damit war es möglich, einen Remote-Ordner von der Synology sichern zu lassen (Ich habe mit der File-Station eine Apple TimeCapsule als Remote-Ordner eingebunden; Datensicherung-und-Replikation konnte dann diesen Ordner als Quelle nehmen um ein Backup mit Version zu machen)

Nun habe ich vor einer Woche endlich mal auf die aktuelle Version 5.2 aktualisiert (einfach um mal einen neueren Stand mit Bugfixes und Sicherheitsfixes zu haben) und bin gerade etwas stinkig…

Version 5.2 kann den Remote-Ordner nicht mehr sichern!

Versucht man so eine Sicherung jetzt anzulegen, geht das gar nicht mehr, weil Remote-Ordner bei der Auswahl als Quell-Laufwerk ausgegraut dargestellt werden. Sie lassen sich gar nicht mehr auswählen! Damit wurde eine für mich wichtige Funktion kaputt gemacht (und mir war es beim durchlesen der Change-Logs nicht aufgefallen)


Meine dringende Frage:
a) Kann ich es irgendwie hintricksen, dass ich als Quell-Laufwerk wieder Remote-Ordner wählen kann um diese lokal auf die Synolgy zu sichern? Ich komme per Telnet oder ssh auf das System und würde es mit Terminal und/oder Tools schon schaffen irgendwelche Config-Dateien etc. zu manipulieren um irgendwo ein Flag zu setzen - wenn ich nur wüsste wo?!

b) Wenn das nicht möglich/bekannt ist: Gibt es eine Alternative für 5.2 um Remote-Ordner zu sichern (am liebsten mit Versionen!)?

c) Wenn alle Stricke reißen: Gibt es einen zuverlässigen und sicheren Weg, ohne Daten-/Konfigurationsverlust zurück auf die 5.1 Version zu kommen? Das passende Paket dafür habe ich mir bereits von der Synology Download-Seite geladen… (das Wiki für den Downgrade kenne ich – Ich las aber von größeren Problemen beim downgrade von 5.2 auf 5.1)

Anmerkung:

Version 6.x kommt noch nicht in Frage, da ich BTSync nutze um Dateien zwischen zwei Macs abzugleichen. BTSync gibt es noch nicht für die 6er Version (nicht offiziell; die Hacks laufen nicht bei jedem reibungslos und mir fehlt die Zeit bei diesem wichtigen Dienst zu basteln und zu testen)



Ich bin für jeden hilfreichen Tipp dankbar. Der Support war bisher nicht hilfreich ("Ich könnte eine neue System-Version installieren und mal gucken, ob es dann geht und ja, Remote-Ordner kann man nicht auswählen" :( )
 
Hallo elastico (interessanter Nick übrigens) und willkommen im Forum.

Synology hat das Sichern von und auf Remote-Ordnern unterbunden, da es in der Vergangenheit immer wieder mal zu Problemen kam. In der DSM-Hilfe kannst du an den entsprechenden Stellen auch nachlesen, das diese Funktion nicht mehr supported wird. Ich persönlich kenne auch keine Modifikation um diese Option wieder zu ermöglichen, jedoch habe ich eine andere Möglochkeit, die du dir mal anschauen könntest... wenngleich hier auch ein wenig Handarbeit nötig ist.

Schau dir mal den Link in meiner Signatur an und lies dir das Wiki aufmerksam durch. Damit sollte auch eine Sicherung von und auf Remote-Ordner möglich sein. Ich drücke mich deshalb so vorsichtig aus, weil ich es nur in der Testphase einmal probiert habe. Auch muß es ja einen Grund geben, warum Synology diese Möglichkeit nicht mehr unterstützt, jedoch kenne ich die genauen Gründe dafür nicht. Daher solltest du dir erstmal mit einer Hand voll Testdaten einen Überblick verschaffen, ob auch alles nach deinen Vorstellungen läuft.

Falls du Fragen oder Probleme beim Einrichten des Script hast, dann melde dich einfach.

Tommes
 
Hey Tommes,

vielen Dank schonmal!
Das Skript habe ich mir mal auf die Synology geworfen und es läuft gerade… (gibt es eigentlich eine Erweiterung um zu sehen, welche Skripte gerade laufen - also außer per Terminal und top? - na egal…) – Mal schauen wann es fertig ist…

Allerdings: Versionierung macht das Skript nicht, richtig? Ich habe am Ende also (immerhin!) eine 1:1-Kopie der externen Platte auf der Synology (besser als nix!) :)

Genial wäre es, wenn das Skript (mit Hardlinks?) Versionsverzeichnisse führen könnte (z.B. über Unterverzeichnisse mit Datum für die letzten n Versionen) – Oder tut es das und ich habe da etwas übersehen? :)
 
Das hört sich doch schon mal alles ziemlich gut an.

Das mit der Versionierung habe ich absichtlich nicht eingebaut, da man für das Rekonstruieren des Backups, bedingt durch die Hardlinks, zwingend ein Linux-System am Start haben muss. Weiterhin ist das zurückspielen eines versionierten Backups nicht ohne, weshalb ich mich letztenendes dazu entschlossen habe zugunsten der Kompatibilität zu Windows keine Versionierung zu verwenden. Auch war ein Grundgedanke dieses Scriptes, ein dateibasiertes Backupssystem zu schaffen, welches man Systemunabhängig rekonstruieren kann, da Hyper Backup dieses in den Anfängen dem Benutzer verwährt hatte.

Tommes
 
Zu dem Teil (Warum keine Versionierung) bin ich inzwischen vorgedrungen - verstehe sie aber nicht ganz…

Das Backup läuft doch auf der Synolgy und diese kann Hardlinks. Würde man nun über das Netzwerk auf so ein Backup zugreifen, sollte es sich für den Client doch wie jeweils vollständige Backups darstellen (der Client bekommt Dateien geliefert, die Hardlinks dürften hier gar nicht Erscheinung treten), oder nicht? Damit wäre ein Zurückkopieren eines Backups eines beliebigen Datums so einfach wie jetzt auch.

Einzig wenn das Backup auf eine externe USB-Platte gemacht wird, kann das Backup dieser Platte nicht zwingend von Windows gelesen werden… Würde man sie aber an eine Synolgy hängen und wieder über das Netzwerk zugreifen…

Oder übersehe ich da etwas wichtiges?
 
Nein, das stimmt alles und wird im auslaufenden Paket Time Backup auch so realisiert. Aber es stimmt auch, dass Time Backup dafür ein Ext4-Filesystem braucht, welches ohne Zusatzsoftware unter Windows nicht gelesen werden kann. Es gibt zu diesem Thema im Forum einen Beitrag zur Nutzung von rsnapshot und ein Skript, das ein versioniertes Backup mittels rsync beschreibt.
 
Ich habe die Versionierung mittels Hardlinks nicht bis ins letzte Detail erforscht, weshalb ich mich mit Vermutungen zurück halten möchte. Fakt ist aber, das ich seit je her ein Systemunabhängiges sowie dateibasiertes Backupsystem ins Leben rufen wollte und da passt eine Versionierung mittels Hardlinks nun mal nicht hinein.

Wer mag, darf sich diese Funktion gerne einbauen und gerne auch der breiten Masse zur Verfügung stellen. Ich werde diese Funktion jedoch nicht einbauen, da ich für mich auch keinen Nutzen darin sehe. Ich arbeite generell nicht versioniert und werde es auch in diesem Script nicht tun.

Sorry für meinen vielleicht forschen Ton, aber ich habe das nun schon öfters diskutiert.

Tommes
 
passt schon :)
Das Skript ist schon wirklich klasse! Und offensichtlich gibt es ja auch anderes Skript mit Versionierung…

Ich wollte mich halt gar nicht mit so etwas befassen – Darum bin ich so stinkig auf Synology! Ich habe Geld in die Hand genommen um eine Komplettlösung zu haben … und ich hatte sie! Bis 5.2 mir diese wichtige Funktion einfach weg genommen hat *grrr*

Wie auch immer… Erstmal scheint Dein Skript gut zu laufen und ein 1:1 Backup ist mir lieber als gar keines :)
Das mit rsnapshot schaue ich mir vielleicht auch noch an :)
 
Echt - Respekt! Dieses rsync-Skript ist schon toll gewachsen

Vielen Dank. Ich werde es auch an PsychoHH weiterleiten, ohne ihn wäre das Script nicht zu dem geworden was es aktuell ist. Er hat ziemlich viele Ideen eingebracht und diese auch umgesetzt. Alleine hätte ich das nie im Leben hinbekommen.
 
Hallo,


a) Kann ich es irgendwie hintricksen, dass ich als Quell-Laufwerk wieder Remote-Ordner wählen kann um diese lokal auf die Synolgy zu sichern? Ich komme per Telnet oder ssh auf das System und würde es mit Terminal und/oder Tools schon schaffen irgendwelche Config-Dateien etc. zu manipulieren um irgendwo ein Flag zu setzen - wenn ich nur wüsste wo?!

Unser Script hast du ja kennengelernt. Versionierung, kann natürlich eingebaut werden. dil88 hat ja auch schon die Passage genannt.
Sonst könnte man rsnapshot nutzen, ich weiß zwar nicht ob es mit Remote-Ordnern klappt aber sonst ist es top.

Ich weiß ja nicht wieviel Platz du auf deiner 1513+ hast und um welche Größe es geht, die du sichern willst.

Wie wäre es denn einfach mit dem Script die Ordner einfach lokal auf DS zu kopieren und von dort dann einfach versioniert zu sichern?
Dauert zwar länger aber rsync ist ziemlich fix.

Sprich: Remote -> rsync Backup -> version Backup.

So hast du immer ein aktuelles 1:1 Backup und das versionierte.
 
Ich weiß ja nicht wieviel Platz du auf deiner 1513+ hast und um welche Größe es geht, die du sichern willst.

Wie wäre es denn einfach mit dem Script die Ordner einfach lokal auf DS zu kopieren und von dort dann einfach versioniert zu sichern?
Dauert zwar länger aber rsync ist ziemlich fix.

Sprich: Remote -> rsync Backup -> version Backup.

So hast du immer ein aktuelles 1:1 Backup und das versionierte.

Die Idee ist nicht so dumm. Ich sehe da nur folgende Haken:

- Derzeit sind es etwas über 600 GB, wovon sich aber nur wenige ändern. Maximal werden es 2 TB, das wird aber noch dauern. Dennoch hätte ich dann immer 2x die 1:1 Kopie (einmal von der ersten Kopie, die als Quelle für das Versions-Backup dient und einmal in dem Versionsbackup. Irgendwie schon Platzverschwendung ;)

- Das Timing zwischen den Backups müsste berücksichtigt werden… Das Versionsbackup sollte nicht starten wenn die Quelle noch befüllt wird… Ob das wirklich ein Problem oder eher akademisch ist, weiß ich noch nicht…


Das rsync-Script läuft bei mir jedenfalls seit 18:09 und jetzt (22:54) noch nicht fertig. Ich sehe es mit "top" noch laufen (zwei Einträge?!). Die Verzeichnisse/Dateien am Ziel sehen auf den ersten Blick zwar komplett aus, ein genauer Blick zeigte aber mind. zwei Verzeichnisse, die noch nicht gefüllt sind… Das scheint also tatsächlich recht träge zu laufen. Keine Ahnung, ob man dem rsync irgendwie einen höheren Datendurchsatz mitgeben kann auf der Maschine.

Ich lass mich mal überraschen… sind einige kleine Dateien dabei, möglich, dass das etwas mehr Zeit braucht. (liegt ja nicht am Skript sondern entweder an meinem Netz oder an der zugewiesenen Leistung auf der Synology)


Das Skript um Versionierung zu erweitern ist vermutlich nicht schwer (gibt ja Parameter für rsync für diesen Zweck) – Nur wie es dann mit dem Aufräumen der älteren Versionen aussieht ist mir noch nicht ganz klar und ich weiß nicht, ob ich mich da wirklich einarbeiten möchte ;) (Wenn eine Datei in einer alten Version gelöscht wird, die später nie mehr geändert wurde, dann darf diese ja nicht verschwinden sondern muss als Quelle für die folgenden Hardlinks erhalten bleiben… Wie das funktioniert ist mir nicht ganz klar - vermutlich alles Parameter-Sache ;) – Ich hatte die Beiträge in dem langen Thread bzgl. der Versionierungslösung gesehen, die Parameter und Aufrufe aber auf die Schnelle nicht wirklich verstanden… muss ich mich mal länger als 5 Minuten mit befassen ;))
 
Nur ein Symlink hat eine "Quelle" und zeigt ins Nirvana, wenn die Quelle gelöscht wird. Ein Hardlink ist ein zweiter Verweis auf eine Datei. Wird eine Datei gelöscht, wird lediglich dieser Verweis gelöscht, der andere bleibt bestehen und damit auch die Möglichkeit, auf die Datei zuzugreifen.
 
Nur ein Symlink hat eine "Quelle" und zeigt ins Nirvana, wenn die Quelle gelöscht wird. Ein Hardlink ist ein zweiter Verweis auf eine Datei. Wird eine Datei gelöscht, wird lediglich dieser Verweis gelöscht, der andere bleibt bestehen und damit auch die Möglichkeit, auf die Datei zuzugreifen.

Was ich meinte, war folgendes:

1. >foo.db< - neue Datei im Backup, 200 MB werden gesichert.
2. [foo.db] (=Hardlink) Datei wurde nicht geändert
3. [foo.db] (wieder keine Änderung)
4. [foo.db] (wieder keine Änderung)

Jetzt kommt die Aufräumschleife und sagt, alles was älter als 4 Sicherungen ist, kann weg. Backup 1 wird also gelöscht.
In Backup 1 liegt aber die echte Datei auf welche die anderen Hardlinks zeigen.

Was passiert dann? Ist das System so schlau zu erkennen, dass es Hardlinks auf diese Datei gibt und die Datei bleibt trotz delete-Aufruf stehen um die Links gültig zu halten? Sprich, das System würde die Datei erst dann löschen, wenn auch der letzte Hardlink gelöscht wurde? (Ich vermute das - Habe damit aber bisher keine Erfahrungen)
 
Genau das habe ich versucht zu erklären: Jede Datei hat einen Verweis. Ein Hardlink ist ein Clone dieses Verweises. Das System löscht Dateien nie, aber es gibt den Speicherplatz zum Überschreiben frei, wenn der letzte Verweis gelöscht wurde.
 
Alles Klar :) Danke für die Klärung/Bestätigung
 
Die Idee ist nicht so dumm. Ich sehe da nur folgende Haken:

- Derzeit sind es etwas über 600 GB, wovon sich aber nur wenige ändern. Maximal werden es 2 TB, das wird aber noch dauern. Dennoch hätte ich dann immer 2x die 1:1 Kopie (einmal von der ersten Kopie, die als Quelle für das Versions-Backup dient und einmal in dem Versionsbackup. Irgendwie schon Platzverschwendung ;)

- Das Timing zwischen den Backups müsste berücksichtigt werden… Das Versionsbackup sollte nicht starten wenn die Quelle noch befüllt wird… Ob das wirklich ein Problem oder eher akademisch ist, weiß ich noch nicht…


Das rsync-Script läuft bei mir jedenfalls seit 18:09 und jetzt (22:54) noch nicht fertig. Ich sehe es mit "top" noch laufen (zwei Einträge?!). Die Verzeichnisse/Dateien am Ziel sehen auf den ersten Blick zwar komplett aus, ein genauer Blick zeigte aber mind. zwei Verzeichnisse, die noch nicht gefüllt sind… Das scheint also tatsächlich recht träge zu laufen. Keine Ahnung, ob man dem rsync irgendwie einen höheren Datendurchsatz mitgeben kann auf der Maschine.

Naja Platzverschwendung beim Backup? Ich weiß ja nicht :)
Wenn man z.B. extra ein volume in der DS intern als "lokales Backup" nutzt und von dort versioniert auf die externe FP sichert, kann es schon Sinn machen.
Du hast dann die letzte Sicherung immer noch mal als Notfall auf der DS falls eine andere Platte kaputt ist.

Du kannst ja einfach in unser rsync Script folgendes machen z.B. hier:

# RSync Exit-Code = Erfolgreich bzw. Unvollständig
#-------------------------------------------------------------------------
if [ -z "$RSYNC_CODE" ] && [ -z "$STOP" ] && [ -z "$ERROR" ]; then
echo "$HR" >> $LOG
echo "RSync-Datensicherung erfolgreich. Sicherungsziel: $DESTINATION" >> $LOG

starte versioniertes Backup .. Dann wird sobald es keinen Fehler gibt das versionierte Backup angestoßen.



Das erste Backup dauert manchmal ein wenig, danach geht es aber echt fix wenn sich nicht viel ändert.
Den aktuellen Status kannst du immer einfach im Log sehen, einfach öffnen.
Dank Syncopt vP siehst du ja noch mehr, hab das auch alles mal durchgetestet und es klappt.
 
Ein komplettes Backup der Synology steht ohnehin noch aus… Bisher war die Synology bei mir ein reines Backup-Medium. Inzwischen liegen aber auch Produktdaten drauf (weil ich sonst nirgends Platz habe) und die müssen nochmal irgendwo hin gesichert werden (Internet scheidet bei meiner Leitung aus).
Es wird also so oder so auf eine zweite (kleine) Synology als zusätzliches Backup hinauslaufen oder auf eine externe USB-Platte (gibt es ja auch mit 8TB wenn ich möchte)


Ich werde aber über das Skript keine Backup-Prozesse verketten. Ich möchte das schon gerne über die Oberfläche regeln können :) Das sind mir am Ende sonst zu viele "unsichtbare" Abhängigkeiten. Das ist aber alles nicht kompliziert zu lösen… Wie Du schon sagst: Folgende Backups sind echt super schnell (nur Änderungen) und so kann man einfach einen folge-Prozess ein oder zwei Stunden später anstoßen um etwas Reserve für große Dateien zu haben…
…oder man macht die Backups jeweils alle zwei Tage im Wechsel etc.

Also nochmals DANKE für den tollen Support hier - ich bin richtig begeistert :)
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat