Ultimate Backup Ultimate Backup

[Tommes]

Ich komme hier zu den selben Ergebnissen. PsychoHH hatte grade eine seiner DS'en auf den 31.12.2017 23:54 Uhr zurückgestellt und dann mehrere Backups gefahren... alles erfolgreich. Wir sind selber noch ein wenig ratlos, suchen aber weiter.

 

[jensi71]

Und so siehts in der Übersicht dann aus, es wird keine Version gefunden (sind aber Versionen bis 31.12. vorhanden)

 

[WoodyT]

EDIT ...gelöscht

 

[reiki]

Nach vielen , vielen Tagen war mein erstes Backup (rund 34 GB) von der 3615xs (zuhause) auf die 115 (extern) über zwei langsame 16er-Internetverbindungen (upload max 1) durchgelaufen. Nach Unterbrechungen lief das Backup auch wieder an und weiter.

So weit so gut. Danke für euer tolles Tool.

Heute morgen entdeckte ich auf dem Backup-Server neben der ersten Hauptversion unter Versionsverlauf eine aktuelle von heute (nacht). Das ist auch gewollt, da ich 5 Versionen eingestellt habe.

Achtung jetzt kommt eine "blöde Laienfrage" und verzeiht mir, wenn ich nicht alle 154 vorgehenden Seiten durchlese. Warum ist jetzt auf dem Zielserver die doppelte Datenmenge (68 GB) belegt ? Dachte bei rsync werden nur die Veränderungen gespeichert, oder liege ich da völlig falsch ? Hat UB auf dem Zielserver alle Dateien kopiert ? Es kann definitiv nicht plötzlich über Nacht passiert sein, dass weitere 34 GB an Daten durchs Web kopiert wurden. Heißt das somit, dass für jede Versionierung die gleiche Datemnemge zusätzlich auf dem Zielserver belegt werden ?

 

[Tommes]

Hey reiki!

Erstmal danke für dein Feedback und das die Versionierung bei dir scheinbar problemlos funktioniert. Wir konnten bisher nämlich auch noch keine Ungereimtheiten feststellen.

Zu deiner Frage, die zwar bereits mehrfach beantwortet wurde, nochmal eine etwas umfangreichere Antwort von mir.

Die Versionierung baut auf Hardlinks auf, wobei es sich bei einem Hardlink um einen direktcodierten Verweis, also einen Link auf einen Ordner oder eine Datei handelt. Das bedeutet, das im Ordner /Hauptversion nur die Dateien synchronisiert wurden, die seit der letzen Sicherung gelöscht, erstellt oder verändert wurden. Alle anderen Dateien werden einfach nur mit einem Hardlink versehen, also einem Link zu dem Ordner oder der Datei die seit der letzten Sicherung eben NICHT verändert wurden. Daraus ergibt sich, das die Kapazität im Sicherungsziel in etwa so groß ist, wie in der Sicherungsquelle bis auf Dateien die zwischenzeitlich gelöscht oder erstellt wurden und noch nicht aus dem Versionierungszyklus gefallen sind.

So ist das Prinzip einer auf Hardlinks aufbauenden Versionierung (ich hoffe ich habe das jetzt auch wirklich richtig erklärt, ansonten bitte ich um Korrektur meiner Ausführungen)

In der Praxis zeigt sich aber immer wieder, das die eigentliche Größe des Sicherungsziels von den meisten Programmen falsch berechnet wird, weil diese einen Hardlink als tatsächliche Datei inkl. seiner Dateigröße sehen und berechenen. Daher summieren sich die Dateigrößen, welche jedoch eigentlich nicht vorhanden sind. Auf der Konsole der DS oder deines rsync-kompatieblen Servers wird dir aber der tatsächliche Wert ausgespuckt.

Dieses Verhalten können wir leider nicht beeinflussen und wir sind uns auch bewusst, das das immer wieder für Disskusionen führen wird.

Tommes

 

[reiki]

Vielen Dank Tommes, dass du dir die Zeit am Sonntagmorgen genommen hast und mir ausführlich geantwortet hast.

Wenn ihr die Final fertig habt, wage ich mich an den "umgekehrten Backup-Weg", mit dem ich neulich noch Probleme hatte (siehe #1441).

 

[reiki]

Kleine Ergänzung zu #1544.

Habe eben per Speicher-Manager auf der DS 115 gesehen, dass dort gesamt nur 41,5 GB belegt sind; inkl. mehrerer GB die auf der DS115 selbst gespeichert sind und nix mit meinem Backup zu tun haben.

Ergo die doppelte Datenmenge meines Backups wird in der Tat nur im File-Manager der DS 115 angezeigt, aber nicht wirklich "physisch" auf der dortigen Festplatte belegt.

 

[QTip]

In der Praxis zeigt sich aber immer wieder, das die eigentliche Größe des Sicherungsziels von den meisten Programmen falsch berechnet wird, weil diese einen Hardlink als tatsächliche Datei inkl. seiner Dateigröße sehen und berechenen. Daher summieren sich die Dateigrößen, welche jedoch eigentlich nicht vorhanden sind. Auf der Konsole der DS oder deines rsync-kompatieblen Servers wird dir aber der tatsächliche Wert ausgespuckt.

Dieses Verhalten können wir leider nicht beeinflussen und wir sind uns auch bewusst, das das immer wieder für Disskusionen führen wird.

Tommes

Das Problem tritt aber nur bei der Größenermittlung des kompletten Zielverzeichnisses auf. Betrachtet man aber nur eine Version, erhält man genau den erwünschten Effekt, um z.B. einen dateibasierenden Vergleich inkl. der Größe der einzelnen Dateien durchführen zu können. Ist der Restore einer Version notwendig, dann erhält man dank der Hardlinks genau die korrekten Dateien für diese Version und muß sich die notwendigen Dateien nicht verstreut über alle Versionen rauspicken.

Wenn ihr die Final fertig habt, wage ich mich an den "umgekehrten Backup-Weg", mit dem ich neulich noch Probleme hatte (siehe #1441).

Bei wichtigen Daten ist ein Restoretest auf jeden Fall anzuraten und anschließend mit der ursprünglichen Quelle zu vergleichen.

 

[Tommes]

Vielen Dank Tommes, dass du dir die Zeit am Sonntagmorgen genommen hast...

Du willst jetzt nicht wirklich wissen, seit wann ich bereits wach bin und an der Finalisierung von Ultimate Backup sitze.

Wenn ihr die Final fertig habt...

... dann mache ich ein Fass auf und werd mich erstmal sinnlos besaufen *lach*
Ernsthaft! Da hier so gut wie keine Bug-Reports von euch mehr kommen, gehen wir davon aus, das Ultimate Backup soweit stabil läuft. Laut dem Downloadzähler von CPHub wurde die Beta bereits gute 600 mal runtergeladen, was ich für ein absolut traumhaftes und überwältigendes Ergebnis halte.

Uns beschäftigt aber immer noch die Versionierung, da es hier bei einigen scheinbar immer noch zu Problemen und Ungereimtheiten kommt. Leider können wir die Fehler in unseren Testumgebungen jedoch nicht reproduzieren, was die Sache für uns um so schwieriger macht. Daher appelliere ich nochmal an alle Beta-Tester uns diesbezüglich weiteres Feedback zu geben, ob bei euch die Versionierung bzw. die Umstellung von der alten Ordnerstruktur zur neuen funktioniert hat.

Ein weiteres ungelöstes Problem ist das hängen bleiben von Ultimate nach einem Upgrade bzw. einer Neuinstallation. Wir konnten den Kreis der Verdächtigen zwar schon weitestgehend eingrenzen, uns fehlt aber noch das letzte Puzzelteil um das Problem abhaken zu können.

Das sind aktuell die letzten Hürden, die wir noch vor der Brust haben, ansonsten steht einer Finalisierung eigentlich nichts mehr im Weg. Man findet zwar immer noch was... so habe ich gestern bestimmt noch 200 Formfehler in der Programmierung beseitigt, die den eigentlichen Programmablauf zwar nicht zwangsläufig stören, aber teilweise unangenehme Log-Einträge produzieren. Wir haben uns einigens dafür jetzt eine Testroutine gebastelt um das komplette System nach ungewollten Log-Einträgen zu durchforsten und stand heute morgen 9:00 Uhr war, das bist auf drei, vier Kleinigkeiten, Ultimate Backup keine Fehler... und seihen sie noch so unbedeutend... mehr produziert und gefühlt habe ich auch den Eindruck, das Ultimate Backup jetzt auch viel flutschiger läuft... was aber auch nur ein subjektives Empfinden sein kann.

Okay Leute, wieder mal habt ihr einen kleinen Einblick in unser handeln und tun bekommen. Ich hoffe es war unterhaltsam für euch.

Tommes

 

[Tommes]

Ah... vielen Dank QTip!

Gleich mal eine Frage an dich. Kannst du mit dieser Fehlermeldung etwas anfangen die wir bekommen, nachdem wir Ultimate Backup nach einem Update versuchen, zu starten. Beim ersten Versuch bleibt UB immer hängen, danach nicht mehr. Es könnte also am Token liegen oder an unserer refresh-Funktion mit AJAX

Auszug aus der /var/log/synopkg.log

2018/01/07 09:00:55 [error] 15494#15494: *92276 access forbidden by rule, client: 192.168.178.123, server: _, request: "GET /webman/3rdparty/UltimateBackup/.url?v=15217-s5&SynoToken=DRPlm4uMQFHIw HTTP/1.1", host: "192.168.178.2:5000", referrer: "http://192.168.178.2:5000/"

Tommes

 

[reiki]

Du willst jetzt nicht wirklich wissen, seit wann ich bereits wach bin und an der Finalisierung von Ultimate Backup sitze. Doch. Nein, ernsthaft auch ich war viele Jahre ehrenamtlich auf einem ganz anderen Gebiet tätig und weiß wie "verrückt" man da manchmal mit den persönlichen Ressourcen umgeht, um ein Projekt fortzusetzen bzw. zu enden.



... dann mache ich ein Fass auf und werd mich erstmal sinnlos besaufen *lach* Prost dann.

.....

Okay Leute, wieder mal habt ihr einen kleinen Einblick in unser handeln und tun bekommen. Ich hoffe es war unterhaltsam für euch. Für mich ja.

Tommes

Freundlicher Gruß

 

[jensi71]

Hi Leute!

So..um nun noch absolute Verwirrung zu stiften:
heute morgen lief die Versionierung mit den beiden USB Jobs einwandfrei!! Lediglich die Sicherung auf die Remote DS ist noch beim Stand 31.12. Das einzige, was ich gestern gemacht hatte, war ja einmal den defekten USB Job manuell (für das Bild hier im Forum) anzuschupsen.

Da brat mir einer einen Storch

Was mir auffiel: das neue Script hat natürlich noch nix zum löschen gehabt (sind noch keine 90 Tage rum bzw. keine 20 Versionen). Das alte Script hat aber nun die Version vom 07.11. gelöscht (könnt ja etwa mit der Versionsanzahl hinhauen).

Ich glaube UB ist vollkommen in Ordnung, nur irgendwas hat sich wohl bei der Übersetzerei verhaspelt (Versionszähler oder so?)
Ich denk, wenn ich nun einfach die Jobs neu anlege, sollt es keine Probleme geben.

 

[Tommes]

1.) Lediglich die Sicherung auf die Remote DS ist noch beim Stand 31.12.

2.) Das alte Script hat aber nun die Version vom 07.11. gelöscht (könnt ja etwa mit der Versionsanzahl hinhauen).

3.) Ich denk, wenn ich nun einfach die Jobs neu anlege, sollt es keine Probleme geben.

zu 1.) Kannst du den Job vielleicht mal manuell starten (kein Dry-Run) und dabei den Haken bei "Fehleranalyse (Debug-Log)" und "Erweiterte Logausgabe (Option —vv)" anhaken und mir das Protokoll anschließend per Mail schicken, die ich dir per PN gebe.

zu 2.) In etwa... gibts nicht.. Wenn du 10 Versionen eingestellt hast dann sollten auch Max. 10 Ordner unter /Versionsverlauf liegen, ausgenommen der gesperrten Versionen. Und der Wert von 90 Tagen betrifft nicht die Versionierung, sondern die Ordner @DSMConfig, @Recycle und @Logfiles.

zu 3.) Unser Ziel ist aber, das man eben nicht nochmal von vorne anfangen muss, sondern man einfach so weiter macht wie bisher. Nur das sich zwischenzeitlich die Ordnerstruktur der Versionierung ändert.

Tommes

 

[jensi71]

Hab Dir ne Mail gesandt.
Grade nachgesehen: hatte das alte Script mit 50 Versionen erstellt. Pro Woche sollten 6 Versionen erstellt werden (jeden morgen um 2 Uhr rum, nur Montag morgens kein Backup). Okay, dann hab ich vielleicht 2-4mal Manuell gestartet, da wird ja jeweils auch eine Version erstellt.

Nochmal Respekt: Punkt 3 ist sehr bemerkenswert und löblich!!

 

[MiniKahn]

Hallo Tommes,

erstmal vielen herzlichen Dank für Ultimate Backup! Bin sehr froh das Programm gefunden zu haben und möchte einfach Danke sagen =)
Ich habe selbst vor einiger Zeit ein paar kleinere Programme für eine größere Anzahl an Nutzern entwickelt, deshalb kann ich es nachvollziehen dass du so enorm auf unsere "Mithilfe" drängst!

Eigentlich wollte ich noch gar nicht schreiben und mein "Problemchen" selbst behandeln, erstmal rumtüfteln und experimentieren.. Aber aus Erfahrung weiß ich, viele Nutzer tun dies eben nicht bzw. wollen dies eben nicht. Sie wollen ein Programm so einfach wie nur möglich.

Ich schildere mein Problem kurz,
Ich habe zur Zeit die Synology DS216j welche bald, hoffe morgen... durch eine DS718+ ersetzt wird. (Virtuallisierung und so n quatsch eben...)
Installierte DSM: DSM 6.2-23511 (Beta)

Habe nun vorgestern ein Backup meiner Daten auf einer externen Festplatte gemacht. (Verlief nach .log einwandfrei.)
Dabei haben ich die Option "Autostart" und "SafeMode" aktiviert.

Ich bin nun davon ausgegangen, wenn ich die externe Festplatte wieder einstecke, dass das Backup automatisch startet.
Allerdings tut es das nicht?
Es ist die selbe DiskStation, selber USB Port, selbe Festplatte.
SSH-Status ist deaktiviert, Autostart aktiviert.

Der Debug.log sieht folgendermaßen aus:


Die Platte scheint also erkannt zu werden? Starten tut das Backup jedoch nicht ....
Hab ich etwas falsch gemacht?

Wie gesagt, die "einfachen" Nutzer wollen so wenig wie möglich selbst tun.. Es sollte einfach mittels ein paar Klicks funktionieren...
Vielleicht weist du auf Anhieb wo das Problem liegt, und kannst es in den "Userflow" implementieren, sodass das Problem nicht irgendwie wieder auftritt?
Vielleicht hab ich aber tatsächlich ja selbst was falsch gemacht :/

Außerdem glaube ich, wurde meine Festplatte nach dem letzten Update nicht ausgeworfen.. so hatte ich das Gefühl..
Würde es aber das nächste Mal gerne nochmal testen...

Vielen Dank im Voraus,
MiniKahn

PS: Habe die gesetzten Variablen noch in den Anhang gehängt..

 

[jensi71]

Hmm glaube bei einem Autostart-Script sollte man bei der Scripterstellung das Namensfeld freilassen. Dann wird der Name "autostart" (oder autorun) gewählt, dann startets auch automatisch!

Lies mal die Hilfestellung, die direkt beim Scripterstellen angezeigt wird. Da stehts drin!

 

[MiniKahn]

"während durch Autostart auszuführende Backup-Aufträge Dateinamen im Format rsync_Scriptname.sh tragen müssen. Wird kein Dateiname angegeben, wird vom System automatisch – autorun – als Dateiname gewählt."

Wenn dieser Satz bedeuten soll, dass ich bei Autostart (nicht autorun!) keinen eigenen Scriptnamen auswählen darf, dann finde ich das sehr schwamming.
Andernfalls würde ich in diesem Fenster dann Abfragen ob ich "AutoStart" nutzen möchte, falls ja, wird das Editfeld ausgegraut und der Scriptname ist fest vorgegeben.....

Ich habe aus diesem Satz gelesen, dass rsync_ und .sh am Ende stehen müssen. "Scriptname" ist zur freien editierung..

Aber erstmal Danke für deine Antwort.

 

[PsychoHH]

Hmm glaube bei einem Autostart-Script sollte man bei der Scripterstellung das Namensfeld freilassen...

Ist nur bei autorun nötig!
Im neuen Ultimate Backup ist das nicht mehr nötig.
Es können alle Scripte automatisch gestartet werden, wenn es in Autostart festgelegt ist.
Sonst laufen Scripte wie "rsync_...sh" oder "autorun".

Habe nun vorgestern ein Backup meiner Daten auf einer externen Festplatte gemacht. (Verlief nach .log einwandfrei.)
Dabei haben ich die Option "Autostart" und "SafeMode" aktiviert.
Ich bin nun davon ausgegangen, wenn ich die externe Festplatte wieder einstecke, dass das Backup automatisch startet

Das sollte auch so sein.

Ich verstehe nicht, warum jetzt mehrere Leute Probleme mit dem externen Pfad haben.
Eigentlich sollten diese so lauten:
/volumeUSB1/usbshare/
/volumeUSB2/usbshare/
/volumeSATA/satashare/

usw ..

Aber nichts mit:
/volumeUSB1/usbshare1-2/

Bitte erstmal mit einer Partition probieren.
Ich werde aber eine debug Ausgabe erweitern.

Du könntest die Platte einmal trennen, DS evtl. neustarten und die Platte neu verbinden.
Nun sollte der Pfad zum Script mit usbshare/ lauten.
Irgendwie scheint es sonst wohl auf find zu hängen

 

[MiniKahn]

Hallo PsychoHH,

das ist meine normale 3TB Externe Festplatte welche ich auch an einem Windowsrechner nutze.
Diese wurde gekauft, mal kurz angesteckt am PC, dann an der Diskstation als Backup.

Natürlich kann ich die Festplatte nun "manipulieren" (Falsche Wort) und daraus eine Partition machen.
Denk aber an die Leute, die sowas noch nicht gemacht haben, die einfach das Einstecken wollen und Backupen.

Gibt es da keine andere Möglichkeit um dem DAU (Dümmsten anzunehmenden User) die usability so gut wie nur möglich zu machen?
Vielleicht ein Hinweis wenn ein Script erstellt wird? Dass die Festplatte so nicht kompatibel ist? Bzw. es doch irgendwie möglich zu machen ohne "Formatierung" der Festplatte?

Liebe Grüße,
MiniKahn

/EDIT 17:30 Uhr

Habe nun das Backup erneut durchgeführt, manuell.
Die externe Festplatte wird nicht korrekt ausgeworfen und wird nach erfolgreichem Backup immer noch angezeigt...??!
Liegt es vielleicht an der DSM 6.2Beta?

LG

 

[Tommes]

Wir haben Ultimate Backup unter DSM 6.2Beta noch nicht getestet. Nichts desto trotz handelt es sich beim erkennen und auswerfen eines USB-Datenträgers um ein Standardprozedere unter Linux und bei mir (uns) funktioniert das auch problemlos. Unser Problem ist daher, das wir nicht für alle Eventualitäten und Gegebenheiten eine Lösung parat haben bzw. anbieten können, solange wir diese nicht kennen bzw. verstanden haben. Es kommt immer wieder vor, das wir von euch über Dinge in Kenntnis gesetzt wurden, von denen wir nicht im Traum dran gedacht hätten, das sowas überhaupt möglich und vor allem praktikabel ist (das ist nicht auf dich bezogen) Von daher...

Ein DAU wird... und jetzt muss ich aufpassen was ich sage um keinen auf die Füße zu treten... wohl immer unsere größte Unbekannte im System sein, da meist nur ein DAU, eben aus seiner Unerfahrenheit, die wildesten Konstelkationen aus dem Hut zaubert, die ein nicht-DAU nicht tun würde. Von daher ist es oftmals schwierig etwas DAU-Freundlich zu gestalten, wenn man die Gedankengänge eines DAU‘s nicht kennt. Ich bin sicherlich ein Freund von Einfachheit und Usability aber man muss auch bedenken, das wir hier nicht nur einen DAU, sondern auch ziemlich hartgesottene Profis dabei haben und unser System von mal zu mal komplexer und damit unübersichtlicher wird. Hier immer das Gleichgewicht zu erhalten entspricht einer Gradwanderung.

Aber wir tun unsere Möglichstes... wie schon seit eh und je.

Tommes