[Projekt] rsync -Alternative dateibasierte Datensicherung

Status
Für weitere Antworten geschlossen.

jugi

Benutzer
Mitglied seit
07. Apr 2011
Beiträge
1.853
Punkte für Reaktionen
0
Punkte
56
Mal eine Frage an die Script Profis.

Warum kann ich so prüfen ob ein Ordner existiert if ssh root@ip test -d $Ordner aber nicht so if ssh root@ip [ -d "$Ordner" ]?

Sollte das nicht trotzdem gehen?
Alter, haust hier son Monsterscript raus und stellst dann so ne Frage… :D

[ -d $Ordner ] "geht nicht durch den tunnel", test macht zwar quasi das gleiche, aber dann eben auf der anderen seite des tunnels.
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Back to the roots!

Nach gestriger Rücksprache mit PsychoHH haben wir uns darauf verständigt, nochmal ganz von vorne anzufangen. Ausgangslage hierfür ist das aktuelle Wiki-Script. Weiterhin wird die Option "Sichern AUF einen entfernten Server (TOSSH)" erstmal aus dem Programm genommen, weil uns das letztenendes das Genick gebrochen hat. Weitere Details zu unserem persönlichen Armageddon lassen wir jetzt mal weg.

Nächste Schritte.
Aktuell sind wir in der Lage verschlüsselte Quellordner automatisch über das Key-File ins System einzubinden und diese im Ziel (erstmal) unverschlüsselt zu speichern. Das funktioniert lokal als auch übers Netzwerk, solang wir die Daten hierbei VON einem entfernten Server auf unsere lokale DS holen (FROMSSH)
Im nächsten Schritt versuchen wir uns daran, auch die Ziele verschlüsseln zu können, wobei es hier bereits noch den ein oder anderen Störenfried zu beseitigen gilt.

Entweder werden wir euch das Script bis zum WE so zum Testen zur Verfügung stellen, das ihr erstmal mit den verschlüsselten Quellen testen könnt (die Beta-Phase möchte ich auf jeden Fall beibehalten), oder aber... falls es gut läuft auch bereits mit den verschlüsselten Zielen. Alles weitere folgt dann "Step by Step"

Ich möchte mich an dieser Stelle auch nochmal bei allen dafür entschuldigen, das wir so auf Kacke gehauen haben und am Ende nur Kacke abgeliefert haben. Sowas wird in Zukunft nicht mehr vorkommen. Wir haben gelernt, das weniger manchmal mehr sein kann...

Tommes
 

dil88

Benutzer
Contributor
Sehr erfahren
Mitglied seit
03. Sep 2012
Beiträge
30.679
Punkte für Reaktionen
2.082
Punkte
829
M.E. gibt es nichts, wofür Ihr Euch entschuldigen müsstet. Seht die Sache so entspannt, wie es Euch möglich ist.
 

Andy+

Benutzer
Sehr erfahren
Mitglied seit
25. Jan 2016
Beiträge
5.357
Punkte für Reaktionen
481
Punkte
189
Würde ich auch mal meinen. Zudem seid ihr euch bewusst, was ihr da macht und verhaltet euch wie Profis das auch tun sollten. Sehr gut, und Hut ab.....
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Seht die Sache so entspannt, wie es Euch möglich ist.

Leider ist das nicht immer mit den Anspruch an sich selbst und meinem Hang zum Perfektionismus vereinbar! Aber ich arbeite daran :D
 

AndiHeitzer

Benutzer
Sehr erfahren
Mitglied seit
30. Jun 2015
Beiträge
3.332
Punkte für Reaktionen
623
Punkte
174
Ich möchte mich an dieser Stelle auch nochmal bei allen dafür entschuldigen, das wir so auf Kacke gehauen haben und am Ende nur Kacke abgeliefert haben. Sowas wird in Zukunft nicht mehr vorkommen. Wir haben gelernt, das weniger manchmal mehr sein kann ...

Nicht dafür!
Ich verfolge den Fred nur aus Neugier, und nicht, weil ich da was brauche.

Aber, und das muss hier mit aller Deutlichkeit gesagt/geschrieben werden, ihr macht das in der Freizeit.
Freizeit ist sehr viel Wert!
Das kann sich normalerweise keiner leisten, geschweige denn kaufen.
Hut ab dafür!

Ich weiss, was ich da geschrieben habe, da ich ehrenamtlich/untentgeltlich 8-10 Stunden je Woche unterwegs bin :)
 

jugi

Benutzer
Mitglied seit
07. Apr 2011
Beiträge
1.853
Punkte für Reaktionen
0
Punkte
56
Kurzer Denkanstoß, wenn ihr jetzt eh neu anfangt:
Versucht das nicht alles in einem Skript unterzubringen, sondern baut verschiedene Skripte für die einzelnen Anforderungen.

Also jeweils ein Skript für:
1. lokal unverschlüsselt
2. auf externen ssh server (server -> client) unverschlüsselt
3. von externem ssh server (client -> server) unverschlüsselt
4. lokal verschlüsselt
5. auf externen ssh server (server -> client) verschlüsselt
6. von externem ssh server (client -> server) verschlüsselt
7. usw…


Ihr habt dann zwar in den fertigen Skripten Code doppelt, aber die könnt ihr euch ja mit nem vernünfigen Makefile zusammenbauen ;)
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Versucht das nicht alles in einem Skript unterzubringen, sondern baut verschiedene Skripte für die einzelnen Anforderungen.

Aber das ist doch grade der Kick bei der Sache - alles unter einen hut zu bekommen und das werden wir so auch hinbekommen.
Aktuell läuft bei mir das Sichern unverschlüsselter Daten sowie das "unverschlüsselte" sichern von Daten aus verschlüsselten Ordnern, die sowohl von Lokal oder aber von einer entfernten DS stammen. Was noch nicht funktioniert bzw. womit ich mich aktuell noch nicht beschäftige ist, die Daten auch verschlüsselt im Ziel zu speichern. Das wäre für mich der nächste Schritt in meiner neuen "Step by Step" Strategie und hier sehe ich auch nicht allzuviele Probleme. Die meisten Probleme haben PsychoHH und ich bereits erkannt, beschrieben und zum größten Teil auch schon Lösungen dafür ausgearbeitet. Daher sollte auch diese Funktion innerhalb eines Scriptes lauffähig sein.

Für mich persönlich wäre das Scipt dann fertig, jedoch möchten ja auch viele von euch nicht nur VON einer entfernen DS sichern, sonder lieber AUF eine entfernte DS. Und hier sehe ich persönlich die meisten Probleme wengleich mir PsychoHH grade eben zugeflüstert hat, das es wohl keine Problem mehr damit gibt. Solange ich mich aber nicht persönlich davon überzeugen kann, bleibt für mich diese Funktion erstmal zu "freaky" um diese in das Script einzubauen. Aber so weit sind wir ja eh noch nicht... und die Zeit wird es Zeigen.

Tommes
 

dil88

Benutzer
Contributor
Sehr erfahren
Mitglied seit
03. Sep 2012
Beiträge
30.679
Punkte für Reaktionen
2.082
Punkte
829
Ein Skript ist im Handling bequemer, aber wenn Du von einem Skript aus andere startest, ist die Funktionalität selbst die gleiche. Vorteil bei dem Verfahren, das jugi vorschlägt, könnte das einfachere Testing sein. Kriegt man aber natürlich auch durch Auskommentieren hin.

Wie immer auch: Ich wünsche Euch neben Fortschritten ausreichend Spaß bei der Sache. Und: Lasst noch genug Platz für Euer Privatleben. ;)
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Ja. Ist schon richtig und macht auch Sinn was jugi und du da vorschlagt und vielleicht kommt auch irgendwann der Punkt wo wir entscheiden werden es genauso zu machen. Für den Moment halte ich die "all in one" Variante aber noch für die elegantere, auch wenn ich mir dessen bewusst bin, mit jeder Erweiterung das Script unübersichtlicher zu machen. Solang man dabei aber den "roten Faden" nicht verliert (was in der Vergangenheit leider aber ein paar mal vorgekommen ist) und man Schritt für Schritt und Block für Block jeden einzelnen Punkt abarbeitet, sehe ich kein Problem darin es auf diese Weise weiter zu versuchen. Und es klappt ja... Mittlerweile haben wir hier bereits soviel Codeschnipsel und Funktionen, das wir alles wie aus einem Baukastensystem zusammen bauen können. Leider passten in der Vergangenheit die Bausteine halt nicht immer richtig ineinander, da jeder von uns beiden andere Vorstellungen, Ansätze und Vorgehensweisen im Kopf hatte... aber ist ja auch Wurst...

Ich will auch langsam mal einen Strich unter die Sache machen, da ich eigentlich bereits viel zu viel Zeit damit verbracht habe und ich langsam auch mal (für mich) Ergebnisse sehen will. Aber mach dir um mein Privatleben mal keine Sorgen dil88, das passt schon alles.

Tommes
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Kurzer Statusbericht!

So langsam wird's Leute....

Die Sicherungsquelle kann sowohl aus unverschlüsselten als auch verschlüsselten Ordnern heraus erfolgen. Ausgehangene, verschlüsselte Ordner können über das Key-File automatisch ein- und nach der Sicherung, falls gewünscht, automatisch ausgehangen werden. Dies funktioniert sowohl innerhalb einer lokalen DS als auch über eine entfernte DS, wobei die Daten hierbei von der entfernten DS auf die lokale DS gespeichert werden (FROMSSH). Alternativ kann ein verschlüsselter Ordner auch ausgehangen kopiert werden, wobei hier der Name @Ordner@ als Quelle anzugeben wäre.

Das Sicherungziel kann ebenso unverschlüsselt als auch verschlüsselt sein, solange sich das Ziel auf der lokalen DS befindet. Bei der Sicherung auf einen externen USB-/SATA-Datenträger geht das aktuell noch nicht, wobei ich nicht weiß, ob das überhaupt geht. Auch hier werden nach Wunsch, über das Key-File eingehangen Ordner nach der Sicherung automatisch ausgehangen.

Was noch nicht funktioniert:
Ist das Ziel ein verschlüsseltes und erstmal ausgegangen, kann das Logfile nicht dort abgelegt werden, da bereits vor dem Einhängen Log-Daten geschrieben werden. Anderseits macht es für mich keinen Sinn dieses Log-File in einem verschlüsselten Ordner abzulegen, ich würde es eher dort ablegen wollen, wo auch das Script gespeichert ist. Wie seht ihr das?

Die DSM-Systemkonfiguration wird auch noch nicht in einem verschlüsselten Ordner gespeichert, wobei sich dieses Problem einfach lösen lassen sollte.

Alles im allen läuft das Script hier bereits sehr gut und zuverlässig. Daher könnte es sein, das ihr vielleicht bis morgen Abend, spätestens aber Anfang nächster Woche mit einer ersten (funktionierenden) Beta rechnen könnt. Ich will mich da aber nicht zu weit aus dem Fenster und somit auf einen Termin festlegen. Aktuell sieht es aber ziemlich gut aus.

Tommes
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Ok, dann wollen wir mal... hier kommt also die erste "laufähige" Beta.

WICHTIG: Außschließlich in einer Testumgebung mit unwichtigen Daten benutzen. Ein möglicher Datenverlust ist nicht auszuschließen. Auch ein mögliches Fehlverhalten der DS kann nicht ausgeschlossen werden, wenn z.B. Ordner nicht richtig ausgehangen wurden, oder Daten fälschlicher Weise im Dateisystem der DS landen. Von daher seid ihr selbst für evtl. auftretende Probleme sowie einem möglichen Datenverlust verantwortlich. Wir übernehmen keine Garantie auf Funktion und fehlerfreien Betrieb. Ihr macht das alles auf eure Kappe.

Was bereits funktioniert...

  • Datensicherung von lokaler Diskstation auf USB-/SATA-Datenträger (unverschlüsselt)
  • Ausführbar über das Such-Script aus dem Wiki
  • Oder über autorun (dazu muß der Script-Dateiname in "autorun" umbenannt werden)
  • Interne Datensicherung z.B. von /volume1/Quelle auf /volume2/Ziel
  • Quellen und Ziel sind unverschlüsselt
  • Eine oder mehrere Quellen sind verschlüsselt, das Ziel ist unverschlüsselt
  • Eine oder mehrere Quellen sind verschlüsselt, das Ziel ist verschlüsselt
  • Interne Datensicherung von einer entfernten Diskstation (FROMSSH)
  • Quellen und Ziel sind unverschlüsselt
  • Eine oder mehrere Quellen sind verschlüsselt, das Ziel ist unverschlüsselt
(Je nach dem könnte man weitere Varianten durch modifizieren des Scriptes erstellen, die ich bisher aber noch nicht getestet habe)

Um verschlüsselte Ordner über das Script einhängen zu können, muß das jeweilige Key-File (der Exportschlüssel) im Ordner des Scripts liegen.


Was noch nicht funktioniert...


Aktuell habe ich noch Probleme, wenn ich bei einer SSH-Verbindung versuche, einen lokal verschlüsselten Ordner (also das Ziel) zu entschlüsseln. Im Protokoll taucht dann folgender Fehler auf (X-Files-DS216 ist ein verschlüsselter Testordner)...

Rich (BBCode):
Verschluesselter Zielordner X-Files-DS216 nicht eingehangen..
X-Files-DS216.key gefunden
Verschluesselter Zielordner X-Files-DS216 wird eingehangen...
Error SYNOShareEncShareMount() failed.[0x1400 share_db_get.c:31]

Was für mich völlig unlogisch erscheind ist die Tatsache, das die verschlüsselten Quellen auf der entfernten DS seinbar eingehangen werden. Dieses Problem habe ich jedoch nur, wenn das Ziel verschlüsselt ist. Ist das Ziel unverschlüsselt, läuft die Sicherung über SSH. Vielleicht hat hier jemand eine Idee.

Weiterhin habe ich den Part - Datensicherung VON einer lokalen DS AUF eine entfernte DS (TOSSH) - erstmal außen vor gelassen. Ich überlasse es PsychoHH diese Funktion wieder an den Start zu bringen. Vielleicht hat ja auch jemand von euch Lust dazu...

Hier nochmal das Fließbild zur Funktionsweise des Scriptes
(Weiter Informationen findet ihr auch im passenden Wiki-Eintrag)

Rich (BBCode):
 Diskstation
    |   |
    |   '--> Aufgabenplaner ------------------------------
    |             |                                      |
    |             '--> Such-Script -----> USB/SATA-Share ---> Ausführungs-
    |                                                    |       Script
    '----------------> USB/SATA-Share --> autorun --------    (Key-Files)
                                                                   |
                                       .---------------------------'
                                       |
                                       V
            .---------- Quelle <--- definiere ---> Ziel----------.
            |                                                    |
            V                                                    V
lokalisiere Quelle(n)                                     lokalisiere Ziel
  |                                                                    |  
  |                             Protokoll                              |
  |-->  Verschlüsselte              |              Verschlüsseltes  <--|
  |  Quelle(n) anhand der   <--- aushängen --->    Ziel anhand des     |
  |  Key-Files einhängen            |            Key-Files einhängen   |
  |          |                      |          (nicht bei USB/SATA/SSH)|
  |          |                      |                   |              |
  |          V                      |                   V              |
  '--------------------->> !! DATENSICHERUNG !! >>---------------------'

Ich wünsche euch viel Spaß beim testen, pobieren, staunen, zittern, bangen....

Anregungen und Kritik erwünscht, noch besser wären aber Lösungen für noch bestehende Probleme, denn so langsam wird das Script für mich lästig *g*

Tommes
 

Anhänge

  • Beta_V001_1704.zip
    4,7 KB · Aufrufe: 5
Zuletzt bearbeitet:

hvkls

Benutzer
Mitglied seit
23. Dez 2012
Beiträge
463
Punkte für Reaktionen
0
Punkte
22
(Beta_V001_1704)

In Zeile 353 steht sinngemäß

rsync -e ssh

und das sollte variabel werden:

RSYNC_REMOTE_OPT="-e 'ssh -p22'"
rsync ${RSYNC_REMOTE_OPT}

da man das leichter anpassen kann, falls der SSHD nicht auf Port 22 lauscht und man außerdem leicht noch eigene Optionen wie --bwlimit o. ä. ergänzen könnte.


In Zeile 231 soll mit "sleep 20" sichergestellt werden, dass das Mounten eines verschlüsselten Volumes erfolgt ist, bevor es weiter geht. Hier wäre vielleicht eine dynamische Wartezeit besser, z. B. eine Schleife, die aber auch nicht ewig läuft. Ich habe ein bisschen den Überblick über die ganzen Variablen verloren, also...

VOLUME=volumeXY
for i in $( seq 1 100 ) ; do
if $( mount | grep -q ${VOLUME} ) ; then
break
else
sleep 1
fi
done
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Danke für dein Feedback, hvkls!

Ich werde deine Vorschläge prüfen und ggfl. einbinden. Aktuell habe ich jedoch noch ein paar Änderungen im Script vorgenommen die ihr bitte mal auf Funktion prüfen solltet. Denn mit dem aktuallisierten Script sollte jetzt nicht nur das...

  • Interne Datensicherung von einer entfernten Diskstation (FROMSSH)
  • Quellen und Ziel sind unverschlüsselt
  • Eine oder mehrere Quellen sind verschlüsselt, das Ziel ist unverschlüsselt
... sondern auch das...

  • Eine oder mehrere Quellen sind verschlüsselt, das Ziel ist verschlüsselt
... funktionieren. Würde mich freuen, wenn ihr das mal durchtesten würdet.

Tommes
 

Anhänge

  • Beta_V002_1704.zip
    4,7 KB · Aufrufe: 3

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Hm... nur 3 Downloads :confused:

Das gibt mir ja ein wenig zu denken und stellt mich vor die Frage, ob dieses Projekt überhaupt von den Benutzern registriert bzw. akzepiert wird? Vielleicht sollte ich auch noch ein wenig die Werbetrommel rühren indem ich euch mal einen Auszug eines Protokolls von mir zeige, wo ich über eine SSH-Verbindung Daten von einer entfernten DS auf die lokale sichere. Dabei werden die Daten aus einem verschlüsselten Ordner der entfernten DS geholt und in einen verschlüsselten Ordner auf der lokalen DS abgelegt.

Kurze Info noch...
U-Files-DS115 ist ein unverschlüsselter Quellordner
X-Files-DS115 ist ein verschlüsselter Quellordner
Und X-Files-DS216 ist der verschlüsselte Zielordner.

Rich (BBCode):
Ausgefuehrtes RSync-Script: Beta_V003_1804.sh

----------------------------------------------------------------------------------------------

SSH-Verbindung zum Server: Backupstation aufgebaut.

----------------------------------------------------------------------------------------------

Verschluesselter Zielordner X-Files-DS216 nicht eingehangen..
X-Files-DS216.key gefunden
Verschluesselter Zielordner X-Files-DS216 wird eingehangen...

----------------------------------------------------------------------------------------------

Unverschluesselter Quellordner homes wurde lokalisiert...
Unverschluesselter Quellordner U-Files-DS115 wurde lokalisiert...
Verschluesselter Quellordner X-Files-DS115 nicht eingehangen..
X-Files-DS115.key gefunden
Verschluesselter Quellordner X-Files-DS115 wird eingehangen...

----------------------------------------------------------------------------------------------

Entfernter Quellordner /homes/admin wurde lokalisiert...
Starte Datensicherung: Backupstation/homes/admin nach Diskstation/X-Files-DS216

[Protokoll an dieser Stelle gekürzt...]
..
.
----------------------------------------------------------------------------------------------
Entfernter Quellordner /U-Files-DS115 wurde lokalisiert...
Starte Datensicherung: Backupstation/U-Files-DS115 nach Diskstation/X-Files-DS216

[Protokoll an dieser Stelle gekürzt...]
..
.
----------------------------------------------------------------------------------------------
Entfernter Quellordner /X-Files-DS115 wurde lokalisiert...
Starte Datensicherung: Backupstation/X-Files-DS115 nach Diskstation/X-Files-DS216
[Protokoll an dieser Stelle gekürzt...]
..
.
----------------------------------------------------------------------------------------------

RSync-Datensicherung erfolgreich. Sicherungsziel: /volume1/ScriptStuff/X-Files-DS216

----------------------------------------------------------------------------------------------

Sicherung der DSM-Systemkonfiguration von Backupstation erfolgreich zu Diskstation kopiert..

HINWEIS: Daten aus dem Ordner /@Recycle, die mehr als 90 Tage alt waren, wurden geloescht.

HINWEIS: Daten aus dem Ordner /@Logfiles, die mehr als 90 Tage alt waren, wurden geloescht.

HINWEIS: Daten aus dem Ordner /@DSMConfig, die mehr als 90 Tage alt waren, wurden geloescht.

Und. Konnte ich euer Interesse jetzt wecken?

Im übrigen habe ich eine weitere Beta geschnürrt, indem ich noch ein paar weitere Fehler ausgemerzt habe und wie von hvkls vorgeschlagen eine neue Variabel für die Konfiguration des RSync-SSHD geschaffen. Ich habe diese jedoch so benannt...

Rich (BBCode):
RSYNCFROMSSH="-e ssh $SSHUSER@$FROMSSH"  # RSync-(FROM)SSH-Verbindung


Im Anhang also noch die neuste Beta

Viel Spaß damit

Tommes
 

Anhänge

  • Beta_V003_1804.zip
    4,8 KB · Aufrufe: 12

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.159
Punkte für Reaktionen
912
Punkte
424
Interesse schon, nur gerade keine Muse und Zeit groß zu testen. Laßt euch dadurch bitte nicht entmutigen. :)
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Ich denke, das PsychoHH noch die Gegenrichtung (TO-SSH), also die Datensicherung von einer lokalen DS auf eine entfernte einbauen möchte und sobald wir das in den Griff bekommen haben, werden wir an der Final und damit auch an einem überarbeiteten Wiki arbeiten. Es wäre halt nur nicht schlecht, wenn auch andere mal eine "BETA" testen würden, damit mir ein wenig Feedback erhalten, was wir verbessern oder verändern sollten oder was evtl. doch noch nicht so funktioniert wie es eigentlich soll.

Aktuell bin ich jedoch mit der aktuellen Beta schon ziemlich zufrieden und bei mir läuft sie schon nahezu perfekt.

Tommes
 

Hafer

Benutzer
Mitglied seit
03. Okt 2014
Beiträge
855
Punkte für Reaktionen
12
Punkte
38
Hey Tommes, nach dem Final ist vor dem Final!

Ich war ja recht überrascht, wieviele Nutzer es wichtig ist, nativ an die gesicherten Dateien zu kommen (selbst bei verschlüsselten Zielen :p). Was ich deiner Ausführung nicht entnehmen konnte, ist eure Positionierung beim Stichwort "INKREMENTELL". Ist da schon was, kommt da noch was? :D
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Hey Hafer,

ich habe in diesem Fred bereits an mehreren Stellen meinen Standpunkt bezüglich "inkrementeller Sicherung" dargelegt. Für mich als Windowsnutzer kann ich mit den Hardlinks, die bei so einer Sicherung erzeugt werden erstmal nichts anfangen da man meines Wissens diese nur unter einer Linux-Plattform zurückspielen bzw. rekonstruieren kann. Auch ging es mir bei diesem Projekt seit eh und je darum, meine Daten dateibasiert zu speichern und diese Plattformunabhängig wieder auslesen zu können.

Nichts desto trotz sollte es ohne weiteres möglich sein, diese Funktion nachzurüsten, ist es doch erstmal nur ein Optionsschalter im RSync-Aufruf. Hier darf jeder der möchte und sich dazu in der Lage sieht, gerne zugreifen und sich diese Funktion einbauen. Denn wer später mal so ein Backup rekonstruieren muss, der sollte auch wissen wie man das Script dahingehend anpassen kann.

Jedoch würde ich vielleicht noch einen Moment warten, da wir kurz vor der Veröffentlichung unserer neuen Version stehen. Ich bin bereits dabei das Wiki umzuschreiben und PsychoHH gibt dem Script grad noch den letzten Schliff um es mit autorun kompatibel zu machen. Es kann also nicht mehr lange dauern... und dann kann man auch mit verschlüsselten Ordner arbeiten.

Tommes
 

Hafer

Benutzer
Mitglied seit
03. Okt 2014
Beiträge
855
Punkte für Reaktionen
12
Punkte
38
Danke für die Rückmeldung.

Ja, es ist "erstmal nur ein Optionsschalter im RSync-Aufruf", aber der will durch eine geeignete Versionierungsstrategie gesteuert werden. Vor ein paar tausend Jahren hatte ich tatsächlich mal mit rsync ein script für (rudimentär) versionierte Backups gebaut - und ja, dazu sind hardlinks nötig, wenn nicht die Platte ratz-fatz zugemüllt werden soll.
Ob dafür NTFS geeignet ist, weiß ich nicht, ich hatte damals EXT3/4 verwendet. Um die unter Windows auszulesen, benötigt man ja schon wieder extfs Treiber - das widerspricht vermutlich deiner Philosophie.

Edit: Ich habe das damals übrigens komplett aufgegeben, weil es zu meinen use cases gehört, große Dateien mit viel Aufwand geringfügig zu ändern - da fliegt einem die Versionierung schnell um die Ohren. Mit DSM 6 scheint das aber kein Problem mehr zu sein (siehe hier) - aber das ist eine andere Story.
 
Zuletzt bearbeitet:
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