Ultimate Backup Ultimate Backup

[Tommes]

Oh, ich habe das auch überhaupt nicht als Kritik aufgefasst und fühle mich auch in kleinster Weise in meiner Ehre gekränkt. Ich möchte oftmals nur die Hintergründe unseres handelns und tun beleuchten, nicht um uns zu rechtfertigen oder um Lob und Tadel zu kassieren, sondern einfach um euch mitzunehmen. Ich finde das halt einfach spannend und es macht mir obendrein auch nichts aus euch einen kleinen Einblick hinter die Kulissen zu geben. Schließlich gestalltet ihr Ultimate Backup ein Stück weit mit. Also alles gut.

Tommes

 

[Tommes]

Workaround für unsere QNAP-Besitzer (sowie andere Serversysteme)

Wir bitten mal um eure Mithilfe!

In Anlehnung des Beitrages von DanielB *klick* (übrigens vielen Dank dafür, das hast damit bei uns eine Initialzündung ausgelöst) haben wir uns mal ein paar Gedanken gemacht, wie wir es schaffen können, selbst mit einschränkten Benutzerrechten eine halbwegs Sinnvolle Datensicherung durchzuführen. Ausschlaggebend waren in diesem Fall diejenigen von euch, die auf eine QNAP sichern wollen. Da wir selber jedoch über keine QNAP verfügen, habe ich das mal Stellvertretend auf einem Raspberry Pi durchgespielt, wo ich als Benutzer „pi“ auch nur über eingeschränkte Rechte verfüge. Sollte der nachfolgende kleine Workaround bei euch funktionieren, würden wir Ultimate Backup in Zukunft wohl dementsprechend umgestalten, so das man, je nach dem über welche Rechte man selber auf dem entfernten Server verfügt, auch nur die entsprechenden Ordner angezeigt bekommt in die man sichern darf und umgekehrt (aktuell sieht man da ja noch alles). Das ist dann zwar noch ein hartes Stück Arbeit, aber irgendwann müssen wir wohl mal damit anfangen. Lange Rede kurzer Sinn…

Erstellt auf dem entfernten Server (QNAP, Raspberry Pi etc.) mal eine SSH-Verbindung mit einem eingeschränkten Benutzer (admin, pi etc.) über die ihr mit der lokalen DS kommunizieren könnt. Wie das genau geht steht u.a. in der Hilfe zu Ultimate Backup.

Jetzt könnt ihr entweder ein neues Netzwerk-Backup anlegen, wobei ihr Daten von der lokalen DS auf einen entfernten Server übertragen wollt. GANZ WICHTIG!!! Achtet dabei bitte darauf, das ihr für das Datensicherungsziel nur die Ordner bzw. Unterordner auswählt, für die ihr auch die nötigen Berechtigungen habt.

Dann ändert im Formular unter „Abschließende Einstellungen“ den Inhalt des Feldes „RSync-Optionsschalter anpassen:“ von

-ahR

… nach …

-ahR --no-g --chmod=ug=rwX,o=rX

Analog dazu erreicht ihr das gleiche auch bei bereits bestehenden RSync-Scripten, indem ihr die Variable „syncopt“ entsprechend verändert...

# Alternative RSync Optionen
syncopt="-ahR --no-g --chmod=ug=rwX,o=rX"

Das sollte reichen, damit ihr eure Daten auch mit eingeschränkten Benutzerrechten auf dem entfernten Server sichern könnt. Was passiert da genau…
DanielB hat es ja bereits sehr anschaulich beschrieben (wir haben das alles nur für unsere Bedürfnisse angepasst), von daher darf ich ihn hier mal zitieren…

Mit der Option --chmod=ug=rwX,o=rX habe ich erreicht, dass beim Erzeugen der neuen Objekte folgende Permission gesetzt werden:
- Verzeichnisse und Unterverzeichnisse mit Permission 775
- Files mit Permission 664.

Mit der option -no-g habe ich erreicht, dass als Gruppe die default Administratorengruppe (administrators) eingesetzt wird.

Beim Eigentümer (Owner) wird der via SSH angemeldete User eingetragen. Es macht jedenfalls den Anschein, dass es so ist.

Seit euch also Bewusst, das sämtliche Besitz- und Gruppenrechte, sowie Ordner- und Dateirechte im Backupziel nicht mehr mit den Quelldaten übereinstimmen.​

Wir würden uns freuen, wenn das der ein oder andere mal testen könnte um zu sehen, ob das auch bei einer QNAP oder sonst einem Server funktioniert. Feedback ist ausdrücklich erwünscht.

GANZ WICHTIG
Bitte verwendet für diesen Workaround erstmal nur Testdasten, also Daten auf die ihr gut und gerne verzichten könnt. Denn das hier ist erstmal nur ein Test​

Tommes

 

[kev.lin]

Ist korrekt so, wird ja als .old gespeichert.
Falls es mal Probleme mit einer neuen Version geben sollte, kann man so das alte wiederverwenden.

Nein, bei mir wird das ursprüngliche Script nicht als ".old" gespeichert. Es wird ein neues Script angelegt und das alte parallel aufgeführt - sowohl in der FileStation als auch in der Übersicht von Ultimate Backup

 

[Tommes]

Dann hat sich da wohl scheinbar ein Fehler eingeschlichen. Bei einem Script-Update wird definitiv die alte Version als .old gesichert. Beim Umbennen ist das scheinbar nicht so. Danke für den Hinweis, wir kümmern uns.... (wir aber wohl noch ein wenig dauern mit der Umsetzung)

Tommes

 

[laserdesign]

Hallo Tommes,

habe mal ein Testszenario aufgebaut.

Was brauchst du jetzt an Daten?? oder sollen wir das per PM machen??

 

[Tommes]

Eigentlich will ich nur wissen, mit welchem System du das getestet hast und ob das Ganze funktioniert hat. Ggf. noch ob die Besitz- und Gruppenrechte sowie Ordner- und Dateirechte dem auf dem Zielserver entsprechen, sprich... du kannst alle Daten auf dem Zielserver öffnen und bearbeiten.

Solltest du jedoch irgendwelche Problem oder Fehlermeldungen haben würde ich die natürlich gerne sehen wollen, entweder hier oder per PM

Tommes

 

[PsychoHH]

Nein, bei mir wird das ursprüngliche Script nicht als ".old" gespeichert. Es wird ein neues Script angelegt und das alte parallel aufgeführt - sowohl in der FileStation als auch in der Übersicht von Ultimate Backup

Alles klar hab das selbst mit dem Script update verwechselt!
Werde mal schauen was ich da mache.
Im nächsten Update ist das dann sicher anders gelöst.

 

[laserdesign]

@Tommes,

habe getestet und lief ohne Probleme.

Quelle DS116 auf Ziel Workstation (w01ub) Ubuntu 14.04 ins /home/fred/syn kopiert

Ob -ahR oder syncopt="-ahR --no-g --chmod=ug=rwX,o=rX"
macht keinen Unterschied.



Quelle DS116

root@syn:/volume1/homes/contact# ll
total 24
drwx--x--x+  4 contact users 4096 Sep 10 09:33 .
drwx--x--x+  7 root    root  4096 Mar  2 19:23 ..
lrwxrwxrwx+  1 contact users   21 Sep 10 07:12 .dovecot.sieve -> sieve/roundcube.sieve
-rwx--x--x+  1 contact users  184 Sep 10 09:33 .dovecot.svbin
drwx------+ 22 contact users 4096 Mar  5 07:49 .Maildir
drwx--x--x+  3 contact users 4096 Sep 10 07:12 sieve

Ziel Workstation (w01ub) Ubuntu 14.04

fred@w01ub:~/Downloads/syn/volume1/homes/contact$ ll
insgesamt 20
drwxrwxr-x  4 fred fred 4096 Sep 10 09:33 ./
drwxrwxr-x  3 fred fred 4096 Mär  2 19:23 ../
lrwxrwxrwx  1 fred fred   21 Sep 10 07:12 .dovecot.sieve -> sieve/roundcube.sieve*
-rwxrwxr-x  1 fred fred  184 Sep 10 09:33 .dovecot.svbin*
drwxrwxr-x 22 fred fred 4096 Mär  5 07:49 .Maildir/
drwxrwxr-x  3 fred fred 4096 Sep 10 07:12 sieve/

 

[kev.lin]

Alles klar hab das selbst mit dem Script update verwechselt!
Werde mal schauen was ich da mache.
Im nächsten Update ist das dann sicher anders gelöst.

Ok, danke für die Rückmeldung.

 

[Tommes]

@laserdesign

Das ist ja interessant. Wenn ich in Richtung Raspberry Pi nur einen -ahR absetzte, erhalte ich einen Code 23 Error (Partial transfer due to error), was wohl der Tatsache geschuldet ist, das der Ordner /web... den ich mal Beispielhaft sichern wollte, dem Benutzer "root" gehört. Dann erhält man nämlich sowas hier...

pi@RaspberryPi:~/Test/volume1 $ ls -la
insgesamt 12
drwxr-xr-x 3 pi pi 4096 Mär  2 17:32 .
drwxr-xr-x 3 pi pi 4096 Mär  5 11:56 ..
d--------- 3 pi pi 4096 Mär  1 19:14 web

Es geht also etwas verloren beim Ordner /web. Führe ich das Gleiche mit mit den Optionen -ahR --no-g --chmod=ug=rwX,o=rX durch, erhalte ich keinen Fehler und /web wird richtig deklariert.

drwxrwxr-x 3 pi pi 4096 Mär  1 19:14 web

Kannst du vielleicht mal schauen, ob das bei dir ähnlich ist. Also mal versuchen einen Ordner zusichern der "root" gehört?

Bis hierhin schonmal Danke für deinen Test.

Tommes

 

[freddiek]

Hi PsychoHH und Tommes,

Ich setzte das von euch kreierte SUPER Script bereits seit den ersten Versionen erfolgreich ein.
Vielen Dank für das was ihr bis jetzt schon geleistet habt und für all das was noch kommen mag

Inzwischen habe ich auch das Upgarde auf die DSM Version 6.0 (bitte nicht mit DSM 6.1 verwechseln) vollzogen.

Was mir bei der neusten Version wieder auffallen ist, sind Verzeichnisse, die nicht gelöscht werden können.
Das habe ich schon mal gehabt (frag mich bitte nicht in welcher Version), danach war lange Zeit Ruhe.

In der Log Datei steht entsprechend "cannot delete non-empty directory: ..."

Könnt ihr euch vorstellen, wo das Problem liegen könnte?

Ich setze die Scriptversion 1.0.2 auf DSM 6.0

Schöne Grüße
freddiek

 

[PsychoHH]

Das sind aber keine @Logfiles oder @Recycle Ordner oder?
Denke mal es liegt da irgendwo an den excludes.

Eventuell hilft die --delete-excluded option im syncopt.

Kannst mir per pn ja mal paar Infos zu kommen lassen.
Wie deine Sicherung genau abläuft und welche Pfade er als Fehler ausspuckt

 

[laserdesign]

@Tommes,

wenn ich /volume1/web mit -ahR sichere, bekomme ich auch den Fehlercode 23.
wenn mit -ahR --no-g --chmod=ug=rwX,o=rX sichere geht es auch nicht, bekomme dann Code 1

 

[laserdesign]

@Tommes,

habe die Rechte von /volume1/web mit chmod 777 /web geändert.

Jetzt lief die Sicherung durch.

 

[Tommes]

Bis hierhin erstmal danke @laserdesign. Ich werde nochmal in mich gehen und noch was mit dem Rechtesystem rumspielen. Denn irgendwie gefällt mir die Lösung noch nicht so ganz, das man sämtliche Rechte über den Haufen werfen muss, nur um eine Sicherung mit eingeschränkten Rechten durchführen zu können. Sicherlich ist das besser als nichts, aber der Eingriff ist in meinen Augen doch enorm. Vor allem wenn man irgendwann mal die Daten zurück auf die DS spielen möchte... das ist alles suboptimal!

Oder hast du da vielleicht eine Idee, wie man das anders oder besser lösen könnte?

Tommes

 

[PsychoHH]

Leider ist das auch nicht so mein Gebiet mit den Rechten.

Mir ist nur mal aufgefallen, dass es bei einer Sicherung auf einen anderen Server einen Unterschied macht ob man jetzt die Rechte per Gruppe oder per Benutzer vergibt.

 

[laserdesign]

ich stecke leider nicht so tief drinne in dem Thema, kann dir keinen konstruktiven Vorschlag machen, Sorry.

 

[Tommes]

Leider ist das auch nicht so mein Gebiet mit den Rechten.

Endlich habe ich mal was gefunden was ich besser kann als du

@laserdesign
Alles gut. Wir werden schon zu einer Lösung kommen, es bleibt halt nur die Frage inwieweit wir das Rechtesystem verbiegen müssen um einen vertretbaren Weg für alle zu finden. Nichts desto trotz bleibt es erstmal ein Fakt, das man nur mit root-Rechten die wohl beste Lösung erzielt.

Tommes

 

[laserdesign]

ich bin der Meinung, das nur root eine Backupstrategie und einen Backupauftrag durchführen darf.
Aber das ist ein anderes Thema.

 

[Tommes]

Das kann ich guten Gewissens so unterschreiben!

Nichts desto trotz wäre es ja eine interessante Option, dieses auch eingeschränkten Benutzern zu ermöglichen. Es zeichnet sich aber bereits jetzt schon für mich ab, das das nur mit einschneidenden Änderungen am Rechtesystem funktioniert und das beißt sich nunmal mit einer sinnvoll angelegten Datensicherung. Aber so schnell geben wir nicht auf...

Wir werden sehen, was am Ende des Tages dabei raus kommt und ob wir eine Sinnvolle Möglichkeit finden oder das Thema als "nicht zielführend" abhaken.

Tommes