[Projekt] rsync -Alternative dateibasierte Datensicherung

[freddiek]

Hallo an alle Helfer und Skriptgötter

@PsychoHH
ich habe deine Änderungen eingepflegt und den Job erneut laufen lassen.
Beide USB Platten drin und es funktioniert tadellos

Sprich DSM 5.2 mit zwei externen und gleichzeitig angeschlossenen USB Festplatten = ALLES OK
Echt cool, jetzt ist es für mich perfekt.

Danke noch mal an alle.

Schöne Grüße
freddiek

 

[PsychoHH]

Das hört sich ja super an.
Dann muss ich das ja nicht noch mal unter DSM 5 testen. Und da es auch unter DSM 6 RC klappt ist es nun auch komplett versionsunabhängig.

 

[Tommes]

Jetzt muss das search-Script nur noch automatisch erkennen, wann ein externer Datenträger angeschlossen wurde...

Das mit der veränderten Suchfunktion nach dem rsync.sh Script klingt ziemlich gut, werde es heute Abend auch mal testen um dann wiederum das Wiki anzupassen. Langsam machst du mich echt Angst, Psycho

Tommes

 

[PsychoHH]

Mit autorun würde dies ja ganz einfach klappen. QTIP hat wohl eine Lösung für die authentication Probleme unter DSM 6.

Wenn die final da ist wird autorun sicher auch für dsm 6 angepasst.


Man könnte auch z.B.noch das Copy Script ändern,sodass ein Backup ausgeführt wird wenn man die Taste drückt. Ob das ein update übersteht weiß ich aber nicht.


Mit der Angst kriegt man es schon zutun wenn man den Nick liest

 

[Tommes]

Einen hab ich aber noch ...

Ich habe dein Search Script kurz angepasst.
Nun kann man einfach die Scripte verschieden bennen z.B. rsyncMusik.sh rsyncBilder.sh usw..
Es geht aber auch Backup.rsync.Musik.sh Hauptsache rsync kommt vor.

OK Psycho, dann setz ich da jetzt auch mal einen drauf.
Man könnte ja auch einfach hingehen und dem Benutzer selbst entscheiden lassen, wie sein Script heißen soll, ohne ihn an den Baustein "rsync" zu knebeln. Ich habe dazu einfach mal ein Array sowie eine for-Schreife in das search-rsync.sh eingebaut, so ist man völlig frei von allem. Man kann den Scriptnamen frei wählen und man kann gleich eine beliebige Anzahl von Scriptnamen vergeben. So werden alle gefunden Scripte, egal ob man vielleicht zwei Scripte gleichzeitig oder nur ein Script von Datenträger XY ausführen lassen möchte, ausgeführt.

Was hälst du davon? Hab das bei mir grad mal mit einem sowie mit zwei Scripten gleichzeitig getestet, die unterschieldiche Namen haben. Teste mal und wenn du das auch für brauchbar erachtest, würde ich das ins Wiki übernehmen. Hier mal das Script...

#!/bin/sh
SCRIPTNAME="Backup-Bilder.sh
	    Backup-Musik.sh"

for SCRIPT in $SCRIPTNAME
  do  
  # Durchsuche volumeUSB1
  if [ -f /volumeUSB1/usbshare/$SCRIPT ]; then
    sh /volumeUSB1/usbshare/$SCRIPT
  fi
  # Durchsuche volumeUSB2
  if [ -f /volumeUSB2/usbshare/$SCRIPT ]; then
    sh /volumeUSB2/usbshare/$SCRIPT
  fi
  # Durchsuche volumeUSB3
  if [ -f /volumeUSB3/usbshare/$SCRIPT ]; then
    sh /volumeUSB3/usbshare/$SCRIPT
  fi
  # Durchsuche volumeSATA
  if [ -f /volumeSATA/usbshare/$SCRIPT ]; then
    sh /volumeSATA/usbshare/$SCRIPT
  fi
done

PS: Meinst du es macht Sinn, im Wiki vielleicht eine Versionsnummer für das Script einzuführen, damit man Änderungen besser erkennen kann?

Mit autorun würde dies ja ganz einfach klappen. QTIP hat wohl eine Lösung für die authentication Probleme unter DSM 6.

Die Frage ist nur, ob Merthos sein -autorun- auch für Hyper Backup anpassen möchte bzw. ob das so einfach geht und wer überhaupt eine datenbankbasierte Datensicherung mit Hyper Backup auf einem externen Datenträger verwenden möchte. Vielleicht bastelt Merthos aber auch bereits an irgendeiner Lösung (reine Spekulation)

Tommes

 

[PsychoHH]

Ja eventuell machen jetzt doch schon ein paar Anmerkungen zu Versionen Sinn.

Bei der Script durchschau ist mir eben volumeSATA/usbshare aufgefallen ich glaube aber das war volumeSATA/satashare.

Ich habe das Script jetzt nochmal angepasst, sodass alle Scripte automatisch gefunden werden mit einer kurzen Abfrage.
Dies funktioniert auch, wenn mehrere Scripte auf einer Platte liegen hat und diese nacheinander abgearbeitet werden sollen.
Ziemlich praktisch, wenn man verschiedene Konfigurationen nutzen will wie z.B. delete usw..

In meiner Beispielkonfiguration muss das Script also den Namen Backup enthalten.
Dies kann man ja aber beliebig ändern.


#!/bin/sh


SCRIPTNAME=Backup




for SCRIPT in /volume*/*share/*$SCRIPTNAME*.sh
do
if [ -f $SCRIPT ]; then
sh $SCRIPT
fi
done

 

[Tommes]

Oh ha... der Wald und die Bäume. Das mit dem satashare hab ich gleich mal im Wiki geändert.

Tja, Variationsmöglichkeiten das Script zu verändern und auf seine Bedürfnisse anzupassen gibt es da wohl haufenweise, wobei deine Codeschnipsel auch immer sehr dazu beitragen, das ganze Script zu "verschlanken", was mir natürlich sehr gut gefällt. Ich werd da auch nochmal ein wenig mit rumspielen und schauen inwieweit man das ins Grundgerüst des Scriptes einbauen könnte... oder sollte... oder ob wir das den Benutzern selber überlassen indem wir ins Wiki evtl. nur die entsprechenden Codeschnipsel anhängen.

Tommes

 

[PsychoHH]

Mir sind gerade noch ein zwei Sachen in den Kopf gekommen die ich wohl noch einbauen werde.
Diese sind dann wohl auch optional.

Damit man es noch "einfacher" hat und leicht Konfigurieren kann.


Die Tage schreibe ich dann nochmal was.

 

[Tommes]

Ja, mach mal

Ich hab grad eh wenig Zeit mich eingehend damit zu beschäftigen. Ich bin also gespannt auf deine Modifikationen...

Tommes

 

[Tommes]

Nachdem uns QTip mit seinem HowTo zu Hyper Backup einen kleinen Seitenhieb verpasst hat blieb mir nicht anders übrig, die von PsychoHH und mir modifizierten Scripte sowie den überarbeiteten Wiki-Eintrag jetzt rauszuhauen. PsychoHH hat da in meinen Augen mal wieder ganze Arbeit geleistet und dieses Projekt ein gutes Stück vorrangetrieben. Dafür eine kurze Verbeugung meinerseits.

Hier also die Reales-Notes vom 11.03.2016...

• Anstatt wie bisher nur eine Backup-Aufgabe ausführen zu können, kann jetzt eine beliebige Anzahl von Backup-Aufgaben auf unterschiedlichen Datenträgern ausgeführt werden.
• Die Script-Dateinamen („search-rsync.sh“ sowie „rsync.sh“) können ab sofort individuell vergeben werden, einzig die Endung .sh muss erhalten bleiben.
• Beim Definieren der Backup-Quellen (SOURCES), müssen keine Volume-Bezeichnungen mehr mitgeführt werden. Es reicht demnach der Pfad eines gemeinsamen Ordners, also z.B. /music/Alben/International
• Über das Benachrichtigungssystems des DSM wird jetzt auch der ausgeführte Script-Dateiname angezeigt.
• Es wurde eine optische- sowie akustische Signalausgabe eingebaut, die optional ausgewählt werden kann.
• Kleinere Script-Verbesserungen und Beseitigung von Schönheitsfehlern.

Viel Spaß damit. Feedback, Anregungen und Kritik weiterhin erwünscht.

Tommes

 

[m0useP4d]

Hut ab für die Arbeit!
Wäre noch schön, wenn der der aktuelle/fertige Script im Startpost dabei wäre

 

[Tommes]

Das geht leider nicht, außer es würde durch einen Mod ständig gepflegt. Und ich denke, das sich das kein Mod antun möchte.

Trotzdem Danke für dein Lob!

Tommes

 

[dil88]

Aber genau deshalb findet sich das Skript ja im Wiki.

 

[Tommes]

PsychoHH und ich waren nicht untätig und haben diesem Projekt noch ein paar Verbesserungen gegönnt. Eine weitere (optionale) Verbesserung, um die Suche nach den auszuführenden Scripten zu vereinfachen steht auch schon in den Startlöchern. Werde das am WE wohl auch noch hinzufügen.

Und wie immer gilt: Erstmal das Ganze mit unwichtigen Testdaten auf Herz und Nieren prüfen, bevor ihr eure Produktivdaten darauf los lasst. Denn trotz intensiver Tests unserseits, ist ein möglicher Datenverlust nicht ausgeschlossen. Wir übernehmen wie immer keine Haftung für mögliche entstandenen Schäden. Ihr macht das alles auf eure eigene Kappe.

Aber wir wollen euch auch keine Angst machen, daher jetzt erstmal die...

Release-Notes (Stand: 18.03.2016)

• Die chronologische Speicherung innerhalb der Systemordner @Recycle und @Logfiles kann jetzt unabhängig von einander über eine individuell einstellbare Zeitvorgabe in Tagen begrenzt werden. Daten, die älter sind als die eingestellten Zeitvorgaben, werden "unwiderruflich" gelöscht.
• Die eigentliche Befehlszeile des rsync-Aufrufes im Script wurde neu strukturiert, indem die Ausführungsoptionen in Variablen ausgelagert, gruppiert und optimiert wurden. Das erleichtert eine Anpassung des rsync-Aufruf an die gewünschten Bedürfnisse.
• Verbesserung der Anzeige und Ausgabe von Datum und Uhrzeit sowie des Script-Dateinamens
• @Logfile Protokolle werden jetzt nach dem Muster 2016-03-18_21h37_[SCRIPT-NAME].log abgelegt
• @Recycle Ordner werden jetzt nach dem Muster 2016-03-18_21h37_[SCRIPT-NAME] abgelegt
• In den Benachrichtigungen und Protokollen wird stets der ausgeführte Script-Dateiname angegeben.
• Viele kleinere Script-Verbesserungen- und Anpassungen

Viel Spaß weiterhin.

Tommes & PsychoHH

 

[Tommes]

Einen hab ich noch *lach*

Viel mir heute so beiläufig ein, das es ja schön wäre, wenn man die DSM-Systemkonfiguration gleich mit sichern könnte. Auch hat PsychoHH eine weitere Variante des Such-Scripts zum Besten gegeben, die ich jetzt auch endlich mal ins Wiki eingefügt habe. Hier also die...


Reales-Notes (Stand: 19.03.2016)

• Ab sofort kann man die DSM-Systemkonfiguration exportieren. Diese wird auf Wunsch in den Systemordner @DSMConfig nach dem Muster DSMConfig_2016-03-19_22h00.dss abgelegt. Weiterhin kann auch hier über eine Zeitvorgabe (in Tagen) eingestellt werden, wie lange die exportieren Systemkonfigurationen erhalten bleiben sollen.
• Eine weitere Variante des Such-Scriptes wurde veröffentlicht um die Suchbedingungen individueller anpassen zu können.

BTW: Wir haben somit bereits 196 Zeilen Code zusammengeschrieben, Kommentar- und Leerzeilen natürlich mitgezählt. *gg*

Tommes

 

[whitbread]

Grosses Lob von mir, auch wenn ich baw bzw. solange möglich den workaround für die Freischaltung der bisherigen filebasierten Sicherung nutzen werde.

 

[Tommes]

Vielen Dank für dein Lob!

Bei dem Workaround befürchte ich jedoch, das Synology dem evtl. irgendwann mal einen Riegel vorschieben wird, sollten sie nicht zu Besinnung kommen und das filebasierte Sichern wieder offiziell supporten. Aber natürlich ist dieser Workaround für den Moment erstmal wesentlich geschmeidiger als dieses Projekt hier.

Nichts desto trotz arbeitet das hier gezeigte Script bereits produktiv um die Daten meiner DS216+ zu sichern. Bis dato hatte ich dafür immer "autorun" verwendet, jedoch mußte in das Startscript immer noch händisch einen rsync-Befehl einbauen, da ich so einen verschlüsselten Ordner auf der DS, unverschlüsselt auf der angeschlossenen USB-Festplatte ablegen konnte. Nun macht das alles mein eigenes Script und bis auf den "autostart" läuft das Ganze ziemlich perfekt würde ich sagen.

Weiterhin lege ich mit D&R aus DSM5 noch eine weitere Sicherung auf meine DS115 an und das soll auch so bleiben. Sollte ich dann irgendwann mal auf DSM 6 wechseln und sollte es bis dahin immer noch keine Möglichkeit geben, filebasiert zu sichern, werde ich mein Script durch einen SSH Zugriff erweitern und dann halt so meine Daten sichern.

Aber wie bereits oft gesagt. Es ist ein absolutes NoGo, was Synology da mit uns treibt, jedoch ist das für mich kein Grund Synology den Rücken zu kehren und zu einem Mitbewerber zu wechseln. Denn bisher hat Synology das ja auch über rsync erledigt und mein Script tut ja nunmal nichts anders. Aber jeder so wie er meint.

Tommes

 

[jugi]

Hm, das Wiki mag mich nicht (kann nix bearbeiten?), daher hier:

Ihr könnt quasi als dritte Variante für das erste Skript selbiges einfach komplett weglassen und das zweite Skript direkt im Aufgabenplaner eintragen.
Der Aufgabenplaner scheint keine Fehlermeldung oder Logeintrag zu machen, wenn er eine Skriptdatei nicht findet und bei eurem Skript wachen (vermutlich) ständig alle angeschlossenen externen Festplatten auf - bei mehreren kann das nervig werden. Außerdem funktioniert es nicht, wenn man (wie ich) ein Dock fix an der DS hat und den Ordner umbenannt hat

 

[Tommes]

Danke für dein Feedback, jugi!

Hintergrund für das Such-Script ist es ja, das eigentliche Ausführungs-Script zu finden, egal ob dieses auf volumeUSB1, 2 oder 3 oder dem volumeSATA liegt. Sicherlich geht das auch ohne, aber so ist man meiner Meinung nach flexibler. Ob oder wo der Aufgabenplaner nicht gefundene Scripte log't habe ich noch nicht weiter recherchiert. Jedoch interessieren mich erstmal die Protokolle der gefundenen Scripte... aber ich begebe mich mal auf die Suche.

Leider verfüge ich über kein Dock Fix, weshalb ich da auch leider keine Erfahrungswerte zur Arbeitsweise und Funktion habe. Vielleicht kannst du hier etwas detaillierter erklären, wie in diesem Fall ein Datenträger anzusprechen wäre, auch wenn ich ich jetzt erstmal behaupten würde, das es da kein Unterschied zu USB- oder SATA- eingebundenen Datenträger geben sollte. Ich lass mich da aber gerne eines besseren belehren.

Auch ist mir nicht klar, was du bei... "wenn man (wie ich) ein Dock fix an der DS hat und den Ordner umbenannt hat" ... genau meinst, was genau du umbenannt hast? Meinst du das Share an sich?

Zu meiner Verteidigung möchte ich jedoch sagen, das es sich hier nur um ein Projekt handelt, was keinesfalls den Anspruch auf Vollkommenheit verfolgt geschweige denn erhebt. Im Gegenteil, jeder ist aufgefordert sich das Script so zu Nutze zu machen und zu verändern, das es den eigenen Bedürfnissen und Vorstellungen entspricht. Ich möchte allen hier nur eine einfach einzurichtende und zu benutzende Basisplattform an die Hand zu geben... nicht mehr und nicht weniger. Es gibt wohl zu viele Eventualitäten, die ich als Privatperson garnicht zu berücksichtigen vermag. Daher bitte ich um Nachsicht, wenn dieses "Grundgerüst" nicht auf jedem Anwendungsfall anwendbar ist.

Tommes

 

[jugi]

Hintergrund für das Such-Script ist es ja, das eigentliche Ausführungs-Script zu finden, egal ob dieses auf volumeUSB1, 2 oder 3 oder dem volumeSATA liegt.

Ich habe den Gemeinsamen Ordner in "icydock" umbenannt, um ihn von der ebenfalls immer angeschlossenen externen HDD besser unterscheiden zu können (die heißt "icybox") - wobei ich gerade sehe, dass zumindest unter DSM6 der Ordner im Dateisystem (wieder?) usbshare heißt… Ich war eigentlich der Meinung, dass der auch da anders heißt… Whatever, damit ist der Teil wohl hinfällig… (Nicht aber die Aufweck-Problematik)

Ob oder wo der Aufgabenplaner nicht gefundene Scripte log't habe ich noch nicht weiter recherchiert.

Unter /var/log und im Protokollcenter ist jedenfalls nix zu finden.

Leider verfüge ich über kein Dock Fix […]

Mein Dock ist fix an der DS, fix wie fest. Blöde Formulierung meinerseits, sorry Das Teil ist fest dran und ich tausche immer nur die HDDs durch…
Damit sollte auch die dann kommende Frage geklärt sein.

Zu meiner Verteidigung möchte ich jedoch sagen[…]

Wieso verteidigst du dich? Lass das, sonst wirkst du wie ein Mädchen

Ich wollte ja auch nur eine weitere Möglichkeit aufzeigen, die in Kombination mit einem "Dock fix" ( ) ggf. sinnvoll sein kann, da der Mountpoint für verschiedene HDDs sowieso immer der selbe ist.