Unregelmäßiges manuelles backup vom NAS auf externe HDD

[aptget]

Ich hab im Heimnetzwerk eine Diskstation 215j seit Jahren durchgängig laufen. Auf dem NAS sind mehrer Hauptordner angelegt (Mutter, Vater, Sohn), sowie die einzelnen User (Mutter, Vater, Sohn) angelegt mit den einzelnen Benutzerprofilen (username, password). Die User können von ihren Windows Laptops aus auf ihre eigenen Ordner auf dem NAS zugreifen, um zB ihre Daten dort zu lesen, speichern usw... nachdem die sich auf der Diskstation angemeldet haben.

Nun möchte ich zu unregelmäßigen Zeiten ein manuelles backup von allen Hauptordnern (+ Unterordnern) durchführen.

Ich hab eine externe HDD (mit ausreichend Platz) die ich per USB an die Diskstation anschließen könnte.

Was wäre die bequemste Möglichkeit das backup (mit den genannten Kriterien) durchzuführen?

 

[RichardB]

Hyper-Backup - muss in Deinem Fall halt manuell angestoßen werden (nicht mein Ding, aber jeder ist seines Glückes Schmied).

 

[ottosykora]

bei uns machen es die Leute mit USBcopy

Tasks erstellen, auf automatisch aushängen stellen

USB Platte einstecken, es macht piepiep
warten bis es wieder piepiep macht und dann kann die Platte ausgesteckt werden

 

[RichardB]

USB-Copy für ein Backup? Ist das dann nicht eher eine 1:1.Kopie?
Wie auch immer das PiepPiep benötigt Menschen. Sind die genauso zuverlässig wie ein zeitgesteuerter Backup-Task?

 

[ottosykora]

Der Grund für so was ist, die Leute machen jede Woche damit ein Backup, ja es ist eine Kopie, ähnlich wie der Hyper Einzel.

Und wenn die es mit Hyper machen würden, dann kann man zwar auch die HD auswerfen automatisch, aber das piept nicht so genau und dann haben die je nach dem die Platte früher abgezogen bevor es fertig war und dann durften wir alle Tasks wieder neu anlegen und den ganzen Backup neu starten etc.
Dann musste sich oft jemand einloggen um zu schauen ob die Platte ejected ist oder ob man sie via DSM ejecten muss etc.
Zu komplex für unsere Kunden weit weg.

Mit USB copy sind die Leute selbstständig, wenn es zum zweitenmal peipeip macht ziehen sie die Platte aus und nehmen sie mit nach hause.
Es sind mehrere Tasks vorhanden, die werden brav der Reihe nach abgearbeitet.
Und ja, eine 1:1 Kopie ist das einzige was hier etwas nutzt, hantieren mit Hyperbackp Explorer kann man den Leuten nicht zumuten.

Nicht alles hightech ist immer nützlich. Machmal sind einfache manuelle Wege von Vorteil.

 

[himitsu]

Ultimate Backup + Autostart

Wenn USB-Platte erkannt wird, dann wird durch Autostart das Backup gestartet.
Am Ende kann man die Platte auswerfen lassen und somit die Platte einfach abziehen, sobals sie ruhig geworden ist.

 

[Tommes]

Ultimate Backup + Autostart…

… funktioniert ab DSM 7 jedoch nicht mehr, weshalb man die App nur noch bedingt empfehlen kann/sollte. Alternativ könnte man unter DSM 7 mit autorun und einem kleinen rsync Script arbeiten um den Effekt des piep-piep und der Vermeidung einer 1:1 Kopie zu umgehen. autorun und rsync sind aber auch nicht jedermanns Sache und ich habe das diese Kombination unter DSM 7 selber auch noch nicht ausprobiert.

 

[himitsu]

Am Ende nutzt Ultimate Backup doch auch "nur" rsync?

Bei mir wurde da jedenfalls ein kleines Bash-Script erstellt, was rsync mit bissl Zeugs drumrum macht.



Unter DSM6 scheint Autorun nun auch nicht mehr ohne bissl manuelles rumgefummel im SSH auszukommen,
oder das im Update ist nur die Meldung für DSM7. (hab das Update noch nicht ausgeführt, was meint man müsse sowas machen)

 

[Tommes]

Da ich Ultimate Backup selber mit entwickelt habe, kann ich dir mit ziemlicher Sicherheit sagen, das die App unter DSM 7 definitiv nicht läuft. Es gehört halt ein wenig mehr dazu als nur rsync, ein kleines Bash-Script und dem bissl Zeugs, damit das alles unter einer GUI läuft! Auch darfst du unter DSM 7 einen rsync Befehl, den du auf der Konsole ausführst, nicht mit einem, über eine GUI ausgelösten rsync vergleichen, da hier teilweise die Rechte einfach nicht die selben sind. Und ohne jetzt zu sehr in Detail gehen zu wollen… unter DSM 7 kannst du dank der neuen Privilegien Steuerung über eine GUI nicht mal einen Ping auf einen Remote Server abfeuern um zu schauen, ob dieser online ist. Und wenn das schon nicht klappt, kannst du dir bestimmt vorstellen, das das mit der GUI gestützten Konfiguration von SSH Zugängen auch eher schlecht bestellt ist, oder um udev für autostart nutzbar zu machen, oder, oder, oder!

Man kann unter DSM 7 über entsprechende Formulare zwar ein GUI gestütztes Konfiguation zusammen klicken und diese Konfiguration dann an ein rsync Script hängen, welches man als root im Aufgabenplaner auslösen kann. Aber das war‘s dann auch schon. Dieses ist mir Ultimate Backup aber so auch nicht möglich, das das über 1000 Zeilen große rsync Script nicht unter DSM7 läuft. Das fängt hiermit an und endet mit ganz banalen Dinge wie Ping usw.

 

[RichardB]

Der Grund für so was ist, die Leute machen jede Woche damit ein Backup, ja es ist eine Kopie, ähnlich wie der Hyper Einzel.

Wenn die Leute, die das machen so zuverlässig sind wie meine Tasks, dann ist alles ok. Ich bin nur von mir selber ausgegangen und ich bin nicht so zuverlässig (abgesehen davon würde ich nur sehr ungern täglich um 03.00 aufstehen, um dann nach und nach 7 Backup-Tasks zu fahren).

Zu den vorteilhaften manuellen Wegen sage ich jetzt nichts weiter, aber Danke für das Bild.

 

[RichardB]

das das über 1000 Zeilen große rsync Script nicht unter DSM7 läuft.

Danke für den 1001 Grund vorab bei 6.2.xy zu bleiben

 

[Tommes]

@RichardB
Vielleicht arbeitet ja auch schon jemand an einer Alternative. Wer weiß das schon….

 

[himitsu]

Als wenn es sooo schwer wäre, für Synology das einzubauen, dass man in dan Paketen die nötigen Berechtigungen definieren könnte, so ala
rights_setup=*
rights_gui=*
rights_backgrondjob|_taskplaner=*

*=root|appname|currentuser|rootifallowed

Und die Nutzer beim Install das dann bestätigen, ablehnen (falls möglich) oder eben das Setup abbrechen kann.
Schon gäbe es das Problem doch garnicht mehr.

 

[Tommes]

Wir driften grade ins Off-topic ab, daher fasse ich mich jetzt kurz.

Bis DSM 7 verfügten quasi alle Apps über uneingeschränkte root Berechtigungen. Da konnte also jeder machen, was er wollte. Das kann man natürlich gut finden, aus rein sicherheitstechnischen Gesichtspunkten ist das aber eher zum Haare raufen. Seit DSM 7 bekommt eine App daher nur dann root Berechtigungen, wenn Synology das für Sinnvoll erachtet und das abnickt. Alle anderen Apps sind erstmal in ihrem eigenen Verzeichnis unter /var/packages/[ APP_NAME] gefangen und kommen da so einfach auch nicht raus.

Es gibt mittlerweile zwar Wege und Möglichkeiten eine App in weitere Benutzergruppen reinzuschmuggeln um an mehr Rechte zu gelangen, aber auch dem sind Grenzen gesetzt. Versuchst du einer App root Rechte zu geben, kannst du die GUI nicht mehr starten (meine Erfahrung). Aus meiner Sicht ist das auf der einen Seite ein absolut großartiger Sicherheitsgewinn, auf der anderen Seite ist es natürlich ein Schlag ins Gesicht für jeden App Entwickler.

Man kann jetzt natürlich den Kopf in den Sand stecken und lieber auf DSM 7 verzichten, oder man stellst sich der Herausforderung und versucht das beste aus der Situation zu machen und neue (andere) Wege zu gehen um ans Ziel zu gelangen. Ich persönlich halte den Sicherheitsgewinn für einen absoluten Mehrwert auch wenn das mit vielen Entbehrungen einher geht. Ich finde es in jedem Fall spannend herauszufinden was geht und wie man vielleicht trotzdem ans Ziel kommt.

 

[himitsu]

Ja, aber es wäre schon bissl einfacher, wenn DSM einem da mehr Möglichkeiten gäbe, wenn es der User dann erlaubt.

Gut, stimmt schon, per se ist es erstmal nicht sooooo schlecht,
aber wenn viele für ihre Apps nun erstmals das halbe system hacken müssen, dann ist das auch wieder kontraproduktiv.
Oder wer erinnert sich, wie hier vor Kurzem jemand ausversehn auf der Platte in zuvielen falschen Verzeichnissen die Berechtigungen verhunzt hatte, damit seine App wieder läuft?