Ultimate Backup Ultimate Backup

[Anthracite]

Ich habe hier ein Problem in der GUI: Mir ist ein Job in der Übersicht verloren gegangen.

Wie das passiert ist, ist unklar. Möglicherweise, als ein Job bereits beim Aufbau der ssh-Verbindung scheiterte (Dyndns-Adresse war in dem Moment ungültig). Aber das ist rein spekulativ, ob da ein zeitlicher Zusammenhang bestand. Ich schaue halt nicht täglich rein.

Ein Klick auf "Auftragsliste aktualisieren" hat nichts genützt. Der fehlende Job wird nicht gefunden.
Der Job ist aber weiterhin da und wird auch ausgeführt.

Um weiter zu kommen zwei Fragen:
- Wie erkennt UB die Jobs/Aufträge, wenn diese im Dateisystem stehen?
- Wo speichert UB, welche Aufträge in der Übersicht angezeigt werden? (Vllt. kann ich die Datei selbst editieren oder eine alte aus dem Backup zurück holen.)

 

[randfee]

ich hab ein Problem auf einer DS, auf welcher ich jetzt auf DSM 7.0 upgraded habe. Kann weder Ultimate Backup updaten noch kann ich es deinstallieren. Mich würde durchaus beides interessieren ;-)

 

[tproko]

UB läuft unter dsm7 leider nicht mehr.

 

[randfee]

ah, too bad :-/. hatte kurz auf den ersten post geschaut und nix gesehen zu DSM7, daher gefragt.

D.h. aber auch, ich kann es nichtmal deinstallieren?

 

[Tommes]

Hi!

Speziell für DSM 7 habe ich Basic Backup entwickelt (siehe meine Signatur). Aktuell hat das Paket aber noch Beta Status und funktioniert auch ein wenig anders als Ultimate Backup. Kannst es dir ja mal anschauen.

Ultimate Backup unter DSM 7 zu deinstallieren geht notfalls über die Konsole… das kann ich aus dem Stehgreif aber nicht erklären. Ist aber schon irgendwie komisch, das du das nicht über das Paketzentrum deinstalliert bekommst.

Tommes

 

[magoxp]

Hallo zusammen,

habe eine Frage zum Verhältnis von Ultimate Backup und Symlinks.
Folgendes Szenario:

Ich habe zwei NAS. Ultimate Backup kopiert auf Wochenbasis von dem einen auf das andere NAS.

Auf "dem einen" (dem Quell-NAS) befinden sich Backups von Backintime unter Ubuntu, das differenzielle Backups mit Hilfe von Symlinks anlegt. So habe ich das zumindest verstanden, und das würde möglicherweise erklären warum mein Ziel-NAS bald aus allen Nähten platzt:
Directories Quell-NAS:
$ du -h --max-depth=1
107G ./20210922-140145-152
42G ./20220131-140001-461
3,4G ./20220404-110002-378
1,9G ./20220321-090001-731
1,7G ./20220124-140001-568
1,1G ./20220215-130001-129
2,8G ./20210927-120001-414
1,5G ./20211025-120001-950
2,8G ./20211004-110001-605
1,5G ./20211210-114931-184
164M ./20220208-130001-469
183M ./20220328-080001-950
8,7G ./20220104-100001-277
1,6G ./20220112-110001-416
1,7G ./20220228-120001-122
6,6G ./20211105-180001-768
1,5G ./20211214-090001-435
1,6G ./20220102-080002-159
1,7G ./20220314-090001-751
2,8G ./20211011-130002-877
1,5G ./20211108-160002-349
2,8G ./20211018-090001-828
1,7G ./20220309-140001-627
1,6G ./20220117-060002-380
198G .

Dasselbe auf dem Ziel-NAS:
$ du -h --max-depth=1
108G ./20210922-140145-152
108G ./20210927-120001-414
108G ./20211004-110001-605
108G ./20211011-130002-877
109G ./20211018-090001-828
117G ./20211025-120001-950
122G ./20211105-180001-768
122G ./20211108-160002-349
123G ./20211210-114931-184
123G ./20211214-090001-435
124G ./20220102-080002-159
131G ./20220104-100001-277
124G ./20220112-110001-416
124G ./20220117-060002-380
124G ./20220124-140001-568
124G ./20220131-140001-461
124G ./20220208-130001-469
124G ./20220215-130001-129
126G ./20220228-120001-122
126G ./20220309-140001-627
126G ./20220314-090001-751
...

Die Ausgabe ist noch nicht vollständig und zählt noch, aber die Reise ist klar.

Ich verstehe allerdings nicht, wie das zustande kommt. UltimateBackup läuft mit
syncopt="-ahR",

-a umfasst -l und das heißt "copy symlinks as symlinks"

Die beiden Verzeichnisse die ich da vergleiche sind beider per NFS gemountet. Ich weiß nicht ob ich da aus irgendeinem Grund nicht "die Wahrheit" sehe.
Irgendwo ist ein Fehler, entweder in meinem Verständnis oder im Tool
Für Tipps bin ich dankbar

Viele Grüße
Marco

 

[himitsu]

Dein Volume auf dem Ziel-NAS ist Btrfs?
Dann kannst du nicht du nehmen, denn das Zählt nur nach Dateigröße, aber beachtet verlinkte Sektoren nicht.

btrfs filesystem du -s /volume1

Aber hier würde ich einfach mal denken, dass in der Quelle unveränderte Dateien zwischen den Backups verlinkt sind (nur einmal Speicher belegen),
aber das kopieren sowas nicht beachtet und diese Dateien dann "mehrmals" speichert, mit jeweil eigenem Inhalt.

 

[Tommes]

Hi!

Ultimate Backup kopiert auf Wochenbasis von dem einen auf das andere NAS. [...] Auf "dem einen" (dem Quell-NAS) befinden sich Backups von Backintime unter Ubuntu, das differenzielle Backups mit Hilfe von Symlinks anlegt.

Backintime als auch Ultimate Backup verwenden Hardlinks, keine Symlinks. Aber das nur am Rande.

Ein Hardlink funktioniert erst mal nur innerhalb eines Dateisystems, daher arbeitet Backintime auf deinem Quell-NAS auch so wie es soll. In dem Moment, wo du die Daten von deinem Quell-NAS auf dein Ziel-NAS überträgst, gehen die Dateisystem- bzw. Hardlink-Informationen verloren. Das Zielsytem behandelt ein Hardlink also als eigenständige Datei und nicht mehr als einen Linkverweis auf die Orginal-Datei. Daraus resultiert, das du auf deinem Ziel-NAS in jeder Version immer alle Dateien überträgst und du somit alles doppelt und dreifach gespeichert ist.

Ein kleines Beispiel:

Ich habe mit Basic Backup einen Versionsverlauf mit aktuell drei Einträgen erstellt. Das sieht dann ungefähr so aus...

root@Diskstation:/volume1/NetBackup/Test/Versionsverlauf# du -h --max-depth=1
301M    ./2022-04-06_17h-01m-51s
148K    ./2022-04-06_17h-02m-35s
148K    ./2022-04-06_17h-02m-41s
301M    .

Dann kopiere ich den Inhalt des Versionsverlaufes auf einen angeschlossenen USB-Datenträger

cp -r /volume1/NetBackup/Test/Versionsverlauf/ /volumeUSB1/usbshare/

Schaue ich mir jetzt den Inhalt des Versionsverlaufes auf dem USB-Datenträger an, dann erhalte ich das hier...

root@Diskstation:/volumeUSB1/usbshare/Versionsverlauf# du -h --max-depth=1
299M    ./2022-04-06_17h-01m-51s
299M    ./2022-04-06_17h-02m-35s
299M    ./2022-04-06_17h-02m-41s
897M    .

Es passiert also genau das, was du beschreibst. Das ist also ein normales Verhalten.

Wenn es bei Backintime (kenne und nutze es selber nicht) auch so einen Ordner wie bei Ultimate Backup geben würde, nämlich /Hauptversion, dann könntest du nur diesen Ordner auf dein Ziel-NAS übertragen. Im Ordner /Hauptversion liegt bei Ultimate- als auch bei Basic Backup immer der aktuellste und damit letzte Versionsstand. Dann könntest du auf dem Ziel-NAS immer nur die Dinge übertragen die sich in der /Hauptversion geändert haben. Aber wie gesagt... ich weiß nicht, ob es solch einen Ordner bei Backintime gibt.

Tommes

 

[synfor]

Auch wenn das im konkreten Fall wohl kaum hilft, es gibt durchaus Programme, die das mit den Hardlinks beim Kopieren händeln könnten:
https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension_de.html
https://schinagl.priv.at/nt/ln/ln.html

 

[matt42]

Hmm, eine Windows Shell Extension auf der Synology, interessant ;-)

Sollten es wirklich hard links sein, wäre -H der richtige parameter für rsync (solange das Zielsystem diese so unterstützt, was ja in Deinem Fall so sein sollte).

 

[magoxp]

@Tommes
Danke für die aufwändige Antwort! Sehr hilfreich
Dass es Hardlinks sind wusste ich nicht.
Auch backintime hat einen Zeiger auf das letzte Backup:
$ll
insgesamt 104
drwxrwxrwx 26 marco users 4096 Apr 4 12:21 ./
drwxrwxrwx 3 marco users 4096 Sep 22 2021 ../
...
drwxrwxrwx 3 marco users 4096 Mär 28 09:21 20220328-080001-950/
drwxrwxrwx 3 marco users 4096 Apr 4 12:21 20220404-110002-378/
lrwxrwxrwx 1 marco users 19 Apr 4 12:21 last_snapshot -> 20220404-110002-378/

Also könte ich nur den kopieren.

Andererseits sollte es ja laut @matt42 möglich sein $syncopts um -H zu erweitern so dass es wie von mir beabsichtigt funktioniert?

Danke schonmal für alle Reaktionen!

Viele Grüße
Marco

 

[himitsu]

oder die einzelnen Wochenbackups übereinander kopieren (nur die Änderungen "neu" schreiben)

* entweder in eine Freigabe/Verzeichnis kopieren, einen Snapschot erstellen und dann darüber die nächste Woche

* oder jeweils die vorherrige Woche in ein neues Verzeichnis kopieren und die Änderungen mit rsync überschreiben (wenn beim Kopieren das Schnellkopieren aktiv war, also quasi mit Hartlinks)

 

[Tommes]

An den Optionsschalter-H habe ich garnicht gedacht. Das müsste eigentlich klappen. Ich teste das morgen mal und werde berichten.

 

[Anthracite]

lrwxrwxrwx 1 marco users 19 Apr 4 12:21 last_snapshot -> 20220404-110002-378/

Also könte ich nur den kopieren.

Das ist die sinnvollste Lösung. Alle älteren Stände ändern sich prinzipiell nicht, und die möchtest du (d. h. dein Backup-Job) auch nicht zeitaufwendig abgleichen.

Alternativ lässt du backintime ohne Versionierung laufen (nur ein Stand) und auf dem Ziel-NAS sorgst du für eine Versionierung.

 

[Tommes]

Hab das mit dem rsync Optionsschalter -H mal eben getestet und es funktioniert. Vielen Dank für den Wink mit dem Zaunpfahl @matt42, da hätte man - also ich - ja auch auch selbst drauf kommen können. Ich habe demnach die rsync Optionsschalter -ahH verwendet und folgendes Ergebnis im Sicherungsziel erhalten...

root@Diskstation:/volumeUSB1/usbshare/Versionsverlauf# du -h --max-depth=1
299M    ./2022-04-06_17h-01m-51s
992K    ./2022-04-06_17h-02m-35s
992K    ./2022-04-06_17h-02m-41s
301M    .

Klappt also. Stark!

Alternativ lässt du backintime ohne Versionierung laufen (nur ein Stand) und auf dem Ziel-NAS sorgst du für eine Versionierung.

Das halte ich für eine sehr gute Alternative zu deinem aktuellen Vorgehen.

 

[_PP_]

Sorry, wenn ich die Lösung bei 143 Seiten übersehen haben sollte, aber ich habe mit UB unter DSM6 ein Problem:

Nachdem ich dem Nerven des Security-Assistenten nachgegeben, und endlich den admin deaktiviert habe, läuft UB nicht mehr mit "user disabled/expired" als Fehler.

Lässt sich das -ohne den admin wieder zu aktivieren- beheben?

Gruß & Dank
Peter

 

[Tommes]

Hi!

Die Fehlermeldung…

ERROR: user has disabled/expired
rsync error: wrong password (code 44) at main.c(741) [sender=3.0.9]
rsync error: wrong password (code 44) at io.c(687) [Receiver=3.0.9]

… besagt, das der rsync Error Code 44 ausgeworfen wurde. Dieser Fehler tritt auf, wenn du das Standard „admin“ Konto deaktiviert hast. Daher ist in der Ultimate Backup Hilfe u.a. zu lesen…

Exit Code 44: Unbekannter Fehler. Prüfen Sie, ob der Standard -admin- Account deaktiviert ist. Dieser muss auf der Quell- und Ziel-DiskStation aktiviert sein.

Daher kann ich deine Frage…

Lässt sich das -ohne den admin wieder zu aktivieren- beheben?

…leider nur mit einem „nein“ beantworten.

Tommes

 

[_PP_]

Danke Tommes ... habe ich befürchtet ... irgendein Eingriff in ein PHP-Script vom Paket o.ä. ist nicht praktikabel, oder?

 

[Tommes]

Mal abgesehen davon, das Ultimate Backup nur ein php Script zur die Abfrage der App Benutzerberechtigung sowie der Auswertung des SynoTokens verwendet und der Rest aus html, css, ein wenig JavaScript und bash besteht, steht es jedem frei, Änderungen, Verbesserungen oder Anpassungen vorzunehmen. Ob das am Ende praktikabel oder zielführend ist, wage ich aber zu bezweifeln. Auch sehe ich aktuell keinen Punkt wo man ansetzten könnte.

 

[framp]

Nachdem ich dem Nerven des Security-Assistenten nachgegeben, und endlich den admin deaktiviert habe,

Sofern ich mich erinnere kann man dieses Nerven abstellen. Da ich kein DSM6 mehr habe kann ich nicht mehr nachsehen wo das genau war. Auf der anderen Seite ist natuerlich die Warnung aus Securitygesichtspunkten durchaus berechtigt. Ich habe deshalb bei mir den admin deaktiviert - aber einen neuen Admin angelegt der aber anders heisst wie admin