Ultimate Backup Ultimate Backup

[exkanzler]

Ist unterwegs.

Gruß
Andreas

 

[kev.lin]

...
Das kann nicht wahr sein woran liegt das denn...
Kannst du mal bitte ein debug log ausführen und mir dann den rsync Teil mal per pn schicken? Da steht sowas wie rsync ssh exclude usw.

Da mich ihr das gleiche Problem plagt: Soll ich ein solches LOG dir auch noch einmal zuschicken?

 

[DanielB]

Ich selbst habe damit viel ausprobiert und bin nur zu einer Erkenntnis gekommen.

Man muss die Rechte bei den gemeinsamen Ordner vergeben.

Sonst habe ich diese immer bei den Gruppen vergeben, allerdings klappt das dann nicht immer bei einer tossh Sicherung.

Um meine gewünschte Permissions, die Gruppe sowie den Eigentümer (Owner) zu erhalten habe ich nun folgende Befehle verwendet:

RSYNC_OPTION="--archive --no-g -i --itemize-changes --chmod=ug=rwX,o=rX "

- mit dem --chmod wird die Permission gesetzt.
- der --no-g wird benötigt, damit bei der Gruppe die Administratorengruppe eingesetzt wird.

Diese Einstellungen werden benötigt, da ein Backup von einem Synology DS215j auf QNAP TS-212 gemacht wird.

 

[Thonav]

Hi Daniel - auch ich habe dieses error 44 Problem.

Kannst Du den code nochmal ein wenig mehr erklären? Was passiert da? Ändert der automatisch in allen gemeinsamen Ordnern die Rechte? Auf welche Gruppe? administratoren?

 

[DanielB]

Hi Daniel - auch ich habe dieses error 44 Problem.

Kannst Du den code nochmal ein wenig mehr erklären? Was passiert da? Ändert der automatisch in allen gemeinsamen Ordnern die Rechte? Auf welche Gruppe? administratoren?

Was ist das error 44 Problem?

Ausgangslage:
In meiner Backup-Anordnung werden die Daten von einer Synology DS215j auf ein QNAP TS-212 übertragen.
Auf beiden NAS ist eine gleichlautende Administratorengruppe (administrators - System default admin group auf Synology und QNAP) und ein gleichlautender Administrator (admin - System default user auf Synology und QNAP) definiert. Aber ich denke mit unterschiedlichen UID's.

Mit der vorgegebenen Options von Ultimate Backup wurden auf dem Zielserver

• die Verzeichnisse und Unterverzeichnisse mit Permission 000
• die Files mit Permission 000
• die Gruppe mit everyone (default Benutzergruppe ohne Admin-Rechte bei QNAP)
• und der Owner mit dem angemeldeten User

gesetzt.

erweiterte Options:
RSYNC_OPTION=" --archive -h --no-g --chmod=ug=rwX,o=rX -i --itemize-changes "

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.

Der Target-Ordner (entspricht dem "Freigabe Ordner bei QNAP" - bei Synology vermutlich dem "Gemeinsame Ordner" ) auf dem Zielsystem wurde nicht geändert, da dieser Ordner bereits vorhanden ist. Bei bereits vorhandenen Ordner und Files wird die Permission auch nicht verändert.

Obiges Verhalten trifft auf meine Backup Anordnung zu. Es entzieht sich meinen Kenntnissen, wie es bei andere Konstellationen aussieht.

 

[PsychoHH]

Nene das hat damit nichts zutun Thonav.
Bei ihm geht es um die Rechte beim übertragen, damit diese erhalten bleiben.

Aber gut, dass es dann auch bei dir geht @Daniel


Ich habe jetzt mal die Logs ausgewertet und auch exkanzler konnte mir paar weitere Logs schicken.
Das "lustige" ist es gibt nun verschiedene error 44.

Einmal
ERROR: user has disabled/expired
rsync error: wrong password (code 44)

und einmal nur:
rsync error: wrong password (code 44)

Der erste tritt auf, wenn man den admin Account deaktiviert.
Ist der admin Account aber aktiviert kann es auch folgenden exit geben:

ERROR: service disabled
rsync error: service disabled (code 52)

Ist Hyper Backup gestartet und nicht gestoppt, geht es in die eine Richtung in die andere nicht.


Und zu guter letzt folgendes: ich kann es bei mir nicht nachstellen.
Ein admin user aktiviert/deaktiviert - klappt
Mehrere admins aktiviert/deaktiviert - klappt
unterschiedliche pw - klappt

Jedes mal laufen die Backups bei mir in verschiedenen Richtungen.
Getestet mit meine x16 DS und auch Docker.


Hat vielleicht ein User noch einen pi oder so übrig auf dem er mal ein Backup testen kann?
Würde mich mal sehr interessieren, ob dort die "zweite" DS Probleme macht.

 

[Tommes]

Kleines Gedankenspiel am frühen Morgen (daher mit Voricht zu genießen)

Was ich bei den Ordner- und Dateirechteproblem von DanielB nicht verstehe ist, das der RSync-Optionsschalter -a das ja eigentlich alles abdecken soll. Ich zitiere mal einen Textausschnitt von hier...

Textausschnitt von Ubuntuusers

Es ist empfehlenswert, die Option -a immer zu benutzen, um alle Rechte und Eigentümer der Quelldatei auf dem Zielmedium zu übernehmen:

-a fasst folgende Optionen zusammen:
-r kopiert Unterverzeichnisse
-l kopiert symbolische Links
-p behält Rechte der Quelldatei bei
-t behält Zeiten der Quelldatei bei,
-g behält Gruppenrechte der Quelldatei bei
-o behält Besitzrechte der Quelldatei bei (nur root)
-D behält Gerätedateien der Quelldatei bei (nur root)

Warum also klappt das bei DanielB nicht und muss sich die Optionen über die RSYNC_OPTION heranziehen ? Entweder wird das Backup bei ihm nicht als "root" ausgeführt, oder die Ordner- und Dateirechte gehen irgendwo verloren... warum und wie auch immer. Aber würde er das Backup nicht als "root" ausführen, könnte er auf dem Ziel nicht alle Ordner- und Dateirechte so mir nichts, dir nichts anwenden. Das ist für mich irgendwie ein Paradoxon.

Wenn wirvaber jetzt mal davon ausgehen, das das Backup, warum auch immer, nicht als "root" durchgeführt werden kann, selbst wenn man das so im Gerätemanager von Ultimate Backup so vorgegeben hat, dann stellt sich mir die Frage: wie soll das gehen?

Denn bei mir laufen alle Backups, egal ob zwischen meinen beiden DS'en oder in Richtung Raspberry Pi. Ich kann auch bei mir weder den Code 44, noch den Code 52 provozieren, egal welche Firewalleinstellungen ich setzte oder nicht. Das der Code 44 mit dem Benutzeraccount zusammenhängt, so wie PsychoHH ja im Beitrag vor mir bereits getestet und das macht ja auch irgendwo Sinn und ist nachvollziehbar. Das der Code 44 jedoch unterschiedliche Fehlerbescheibungen ausspuckt ist mir hingegen ein Rätsel. Auch findet man im Internet so gut wie nichts zum Code 52, das ist doch verrückt.

Ich bin also der Auffassung das das Problem primär erstmal nicht an Ultimate Backup liegen kann, sonst dürfte es bei keinem von euch funktionieren. Dem ist aber scheinbar nicht so. Daher bleibt die Frage offen, was der Grund für diese... ich nenn sie mal "Anomalie" ist.

Das herauszufinden scheint aktuell ein unlösbares Problem für uns zu sein.

Tommes

 

[dil88]

@DanielB: Ich würde es einmal mit gleicher uid und gid testen. Dafür am besten ein kleines Testverzeichnis einrichten und einen entsprechenden Test-Datensicherungsjob unter Ultimate Backup erstellen.

 

[voodoopupp]

Hallo,

ich hab da mal eine Frage, für die ich noch keine Antwort gefunden habe:
was passiert, wenn ein Backup Job läuft und der Energie-Zeitplan eigentlich das NAS herunterfahren möchte?

Also wird dann der Backup-Job erst noch komplett fertig ausgeführt und erst danach fährt sie runter, oder wird der Backup Job unterbrochen?

Grüße
Voodoopupp

 

[Alexme]

So, mit der neuen Version (1.0.2) habe ich jetzt wieder das Problem, dass die Fehlermeldung: .ddns.net nicht in der known_host eingetragen! auftaucht. Habe auch nochmal versucht die SSH Schlüssel auszutauschen, waren aber bei beiden schon vorhanden. Auf beiden NAS läuft die gleiche Version. Kann es sein, dass der Code für DDNS nicht in die neue Version eingeflossen ist?

Ahja, und irgendwie verstehe ich anscheinend die Versionierung nicht, ich versuche das mal in Worte zu fassen:

Meine Vorstellung war, dass nicht alle Dateien neu geschrieben werden, sondern nur neue Versionen erfasst werden und diese gesichert werden. So zumindest die allgemeine Definition.

Momentanes Verhalten: Wenn ein Backup angestoßen wird, werden obwohl sich nichts geändert hat, alle Dateien erneut auf die Platte geschrieben. Dabei werden sie zwar nicht von ihrem alten Ort (sprich vom entfernten NAS) kopiert, sondern direkt von der NAS auf dem die Sicherungsdateien liegen, aber es macht die Festplatte voll. Bzw. tut es das anscheinend irgendwie gar nicht. Arbeitet das mit Verweisen?

Es ist so auch nicht zu erkennen (zum Beispiel im Falle einer Veränderung von X Dateien durch Virus, etc), welche Dateien denn nun befallen waren.

 

[Scirocco3]

Problem mit 2ter NAS (QNAP)

Moin Moin zusammen,

ich hab da ein kleines Problem(chen) ;-)

Ich sichere meine Daten immer auf meine alte QNAP TS-459 Pro II.
Normalerweise starte ich die Sicherung über diese dann per FTP oder Rsync.
Jetzt wollte ich aber das ganze auf die performantere DS916 legen und hab dann mal UB versucht.

Ich sehe aber keine Quellen auf der anderen NAS wenn ich einen Auftrag erstellen möchte.
Ich fasse mal zusammen was ich alles gemacht habe.

1) RSync (873) & SSH (22) auf der QNAP aktiviert.
2) Die beiden Handshakes durchgeführt und die QNAP wird auch grün gelistet mit Handshake erfolgreich.
3) Die Verbindung (Rsync-kompatibler Server) habe ich erstellt mit dem Benutzer "root" wie er vorgegeben ist und den Port von RSync auf die 873 der QNAP eingestellt. SSH bleibt auf 22.

Ich sehe aber wie gesagt keine Quellen der QNAP. Ich kann auf der QNAP auch einen anderen RSync User einrichten (notwendig falls der Remote-Server keine NAS ist), aber wenn ich den aktivieren würde, muss ich ein PW hinterlegen. Und das könnte ich wiederum nicht in UB eintragen.
Muß ich bezüglich des Users root auf der QNAP noch was machen?
Dort gibt es nur den Admin und meinen. Beide haben die selben Namen und PW wie auf der DS916.
Auch klappt es nicht wenn ich statt root den Usernamen Admin nehme.
Und wie gesagt, ich kann ja kein PW zu dem User hinterlegen, also nehme ich an das es zwingend der "root" sein muß.

Ich denke es muss an dem User root liegen. Ich kann mit dem User Admin und dem passenden PW ein SSH login machen. Nehme ich aber als User root, fragt er auch nach einem PW und ich komme nicht rein.

Habt ihr eine Idee woran es liegt, bzw. wo ich was vergessen habe einzustellen?
Thx

*EDIT*
Was auch eigenartig ist.... Ich hab mal ein lokales Script zum testen angelegt.
Er findet es nach dem anlegen nicht mehr. Es liegt in der Root der ersten Freigabe.
Aber unter Aufträge wird nichts gefunden, und im Zeitplaner kann ich dann auch nichts sehen/eintragen.
Auch ein Restart des UB Dienstes brachte zu keinem Punkt eine Veränderung.

 

[Tommes]

@Voodoopupp
Der eingestellte Zeitplan nimmt keine Rücksicht auf laufende Prozesse und fährt daher die Diskstation zum angegeben Zeitpunkt runter.

@Alexme
Zum Problem mit der DDNS kann ich grad nicht viel sagen, wir prüfen das aber. Die Versionierung verhält sich anders, als es den Anschein hat, soll heißen... es sieht zwar so aus als ob stehst komplette Datensätze kopiert werden, in Wirklichkeit wird aber nur die Änderung gespeichert. Die Grundlage wird hier durch die Verwendung von Hardlinks geschaffen. Die Filestation berechnet die Kapazität eines Backupset's falsch, auf der Konsole sowie unter Ultimate Backup wird im Gerätemanager die wahre Kapazität angezeigt.

@Scirocco3
Wir wurden schon an anderer Stelle im Forum über Probleme mit einer QNAP angesprochen. Problem hier ist erstmal, das weder ich noch PsychoHH über eine QNAP verfügen um das alles mal zu testen. Wir müssen also schauen wie wir hier die Kuh vom Eis bekommen. Aktuell haben wir aber noch keine Lösung dafür.

Tommes

 

[Scirocco3]

Denke es liegt daran das die QNAP keinen root User mehr hat. Und wenn man dann einen anderen anwählen will, fehlt die PW Eingabe für diesen.
Evtl. reicht es diese Möglichkeit, ein PW mitzugeben, einzubauen. Oder gibt das der rsync Befehl nicht her?

Und weist meinst Du zu dem Punkt das ein angelegtes Script nicht gefunden wird?
Und zum testen eines evtl. angepassten/neuen UB's könnt ihr gerne auf mich zukommen.

 

[dil88]

Auch wenns OT ist, eine kurze Nachfrage: QNAP hat auf der Shell keinen root User, das kann ich mir kaum vorstellen. Oder ist es wie bei Synology seit DSM 6.0, dass man sich nicht als root anmelden, aber auf der Shell root werden kann?

 

[TeXniXo]

Ich tipp auch stark auf deine Vermutung (analog zu DSM 6.0 beim Synology).

On Topic:
Gehe ich richtig in Annahme, dass Ultimate Backup 1.0.2. gar keine 3rd Apps mehr benötigt und deshalb mit der DSM-Version 6.1 ("streitet" ja gerne mit 3rd Init) keine Probleme hat?

 

[dil88]

Ja, 1.0.2 braucht das init_3dparty Paket nicht mehr.

 

[Scirocco3]

@dil88
Genauso.... zumindest nach meinem Kenntnisstand. Aber ich habe ein offenes Ohr wenn jemand andere Info's hat.
Fakt ist das es sogar "alte" Anleitungen gibt wie man einen root user anlegt (passwd und shadow modifizieren).
Aber das klappt auch nicht mehr.

 

[Tommes]

Mit Einführung von Ultimate Backup 1.0 haben wir komplett von html/php auf html/bash umgestellt, einzig die Initiierung des DSM-Berechtigungssystems, den sogenannten Syno-Token lief noch über php und dafür brauchten wir Init_3rdParty. Erst durch die aufkommenden Probleme mit DSM 6.1 und Init_3rdParty wurde uns bewusst, das wir php auch über den Systemapachen nutzen konnten. Daher benötigen wir jetzt weder ein php-Paket noch Init_3rdParty.

Und zum Problem mit dem nicht auffinden des Scripts, kann ich grad nicht viel sagen, da bei mir bisher immer alle Scripte gefunden wurden. Liegt das Script denn im Angegeben Ordner und falls ja, welche Rechte hat die Datei?

Tommes

 

[TeXniXo]

Danke für die Infos, Tommes! Hut ab vor eurer Leistung und dass ihr stets mit der Zeit (siehe Update DSM 6.1) mitgeht!

 

[Scirocco3]

@tommes

Ja, ich hatte es ursprünglich in dem Ordner "Ablage/Scripte" den ich angeben hatte.
Und als es nicht gefunden wurde, hab ich mich an den anderen Satz in der Anleitung gehalten... das es gut wäre wenn es in der Root liegt....
und habe es dann dort auch noch mal hin kopiert.

Sucht er evtl. so lange ?
Weil er sagt immer "Bitte warten ... Backup-Aufträge werden gesucht". Das müsste doch eigentlich auch mal weggehen und entweder leer sein, oder einen "gefundenen" Inhalt haben, oder?