[RC] DSM 6.0 - 7307 (RC): Erfahrungen, Probleme, Bugs

[ralfi80]

Angenommen du bist im Ausland und deine Haupt DS ist aus/geklaut/gekauft oder sonst was such es dir aus. Jedenfalls kannst du Sie nicht nutzen.
Jetzt brauchst du aber Daten und willst auf dein Backup zugreifen. Seien es nur, Flugtickets, PW Datenbank, Ausweisdokumente

Also man fliegt sozusagen ohne Ausweis und Flugtickets ins Ausland und die Frau zuhause verkauft währenddessen die DS

Die sachlichen Argumente gegen dieses Hyper Backup (Datenbank korrupt) hatten wir ja schon. Aber langsam wird´s abenteuerlich

 

[xamoel]

Und ganz einfach der Zugriff aufs Backup. Aktuell kann ich von jedem PC/DS was auch immer einfach die Dateien öffnen. Das geht jetzt nicht mehr.

 

[eddie irvine]

Wem die neuen Funktionen des Hyperbackups gefallen soll sie auch nutzen aber die paar Zeilen Code für das alte backup tut auch keinem weh da es ja keine Arbeit mehr macht.

Ist es nicht so, dass bestehende DSM 5.2 Backup Jobs (also auch dateibasierte) in DSM 6 übernommen werden?

 

[Puppetmaster]

Ja, das ist so. Aber was nutzt das?

 

[eddie irvine]

Ja, das ist so. Aber was nutzt das?

Gibt es dann keine Möglichkeit, die irgendwie unter DSM 6 zu erstellen?
In welcher Form sind diese Jobs denn gespeichert?

 

[xamoel]

Nur manuell, nach Tommes Anleitung. Aber neue Jobs können nicht erstellt werden, offiziell. Das ist ein Mist.

 

[Matthieu]

Fast jedes mit bekannte Dateisystem nutzt eine Datenbank, nennt sich dort eben Journal. Nennt sich bei NTFS "MFT", bei ext journal, usw. Warum soll es dann bei einem Backup etwas schlimmes sein? Klar gibt es Nachholbedarf. Ich habe auf der CeBIT zum Beispiel die redundante Haltung der Datenbank angeregt, ähnlich einiger Dateisysteme. Mal sehen was daraus wird.

Ich kann auf jeden Fall sagen dass Synology auf der CeBIT sich der Diskussion bewusst war und eine endgültige Entscheidung seitens Taiwan bzgl. final noch aussteht.

Aber ja gibt mir ruhig noch eine Verwarnung, langsam wird das zum Kindergarten, wenn man nicht mal vor btrfs/Hyper Backup warnen darf.

Du darfst hier sagen was du möchtest, aber das Thema HyperBackup artet vermehrt aus und wird sehr emotional und wenig sachlich geführt. Wenn ich mir das so anschaue wären eigentich viel mehr Eingriffe nötig damit wir wieder zu einer Diskussionskultur zurückkommen die dieses Forum einst groß und beliebt gemacht hat. Trifft nicht alles auf hier zu, daher spare ich mir die Belege, generell kommt aber oft zusammen:
- Behauptungen werden nicht belegt, technische Sachverhalte übermäßig vereinfacht und somit falsch oder aus dem Zusammenhang gerissen
- Gegenargumente werden mit persönlichen Angriffen statt sachlichen Antworten erwiedert
- Themen werden quer über Threads hinweg diskutiert, OT wird dafür in Kauf genommen bis die eigentliche Diskussion damit nichts mehr zu tun hat und alles andere untergeht
- Einzelfälle werden generalisiert, Sachverhalte dramatisiert ohne eine technische Ursachenforschung abzuwarten oder auch nur zu ermöglichen
- desktruktive Kritik

Nichts davon gehört in dieses Forum. Verwarnungen wie alle anderen Entscheidungen auch können per PN an die Moderatoren oder E-Mail an den admin eingehender diskutiert werden.

MfG Matthieu

 

[Puppetmaster]

Fast jedes mit bekannte Dateisystem nutzt eine Datenbank, nennt sich dort eben Journal. Nennt sich bei NTFS "MFT", bei ext journal, usw. Warum soll es dann bei einem Backup etwas schlimmes sein?

Weil's proprietär ist und von all meinen Clients nicht nativ gelesen werden kann.

Das ist doch immer dasselbe Ding in immer neuen Formulierungen.

 

[X5_492_Neo]

Warum denn ne Verwarnung Psycho? Los ab mit dir in die Schäm dich Ecke!

Ich hab mir das Webinar gestern auch mal angeschaut, logischerweise scheint das sehr auf Verkaufsargumentation der Schwerpunkt zu liegen und scheint für sich gesehn schon stimmig zu sein! Auch wenn es denoch fail ist! *MichzuPsychoindieSchämdichEckestell*

 

[Andy14]

Fast jedes mit bekannte Dateisystem nutzt eine Datenbank, nennt sich dort eben Journal. Nennt sich bei NTFS "MFT", bei ext journal, usw. Warum soll es dann bei einem Backup etwas schlimmes sein?

Das darunterliegende Dateisystem (mit seinen möglichen Fallstricken) fällt ja mit HyperBackup nicht weg! Es kommt aber eine neue "Schicht" dazu, die selber defekt gehen kann!

 

[Matthieu]

Es kommt aber eine neue "Schicht" dazu, die selber defekt gehen kann!

Weil man nur so unabhängig vom Dateisystem ist. Ansonsten würde Synology gleich noch ein eigenes Dateisystem einführen. Na da wäre ich auf die Reaktionen gespannt. Es geht mir eher um das technische Prinzip. Wie oft steigt ein Datenträger in der Praxis aus weil ein Journal zu viele Fehler hat? Das Prinzip einer Datenbank kann durchaus funktionieren.

Nicht das mich jemand falsch versteht: Auch ich will ein einfaches, dateibasiertes Backup im DSM. Dann aber ein ganz schlichtes ohne Versionierung und allen anderen Schnickschnack, damit der Wartungsaufwand und die Anzahl der Fehlerquellen möglichst klein ist. Ich stelle mich hier aber gerade in die andere Ecke weil HB durchaus eine Daseinsberechtigung hat und wir hier nicht in einer Hau-Drauf-Bude sind. Da sollte eine sachliche Diskussion über Vor- und Nachteile (und ja, die derzeitige Umsetzung der DB ist eher letzteres, aber auch NTFS ist nicht mit einer Version zu dem geworden was es heute ist) schon drin sein.

MfG Matthieu

 

[Puppetmaster]

...aber auch NTFS ist nicht mit einer Version zu dem geworden was es heute ist.

Langsam bin auch ich müde ob dieser Diskussion.
Also nochmal: Wieviele Endgeräte können NTFS lesen? Wieviele dagegen Synologys Hausgebräu?

Hier ist doch ganz klar die Verbreitung in der Fläche das Entscheidende.
Und letztlich gab es selbst in der Anfangsphase von NTFS nicht den Fall, dass eine korrumpierte Datei das gesamte Backup zerstören konnte, wenn es eben filebasiert ist.

Ich habe auch gar nichts gegen HB, vorausgesetzt, das alte Backup bleibt bestehen.

Mit Windows 10 ist es schließlich auch noch möglich, NTFS zu lesen. Und selbst wenn MS auf die Idee kommt, ein neues Filesystem zu implementieren, werden sie das alte damit ja nicht abschalten.

 

[cmdr_tom]

Es steht jedem frei sich für QNAP zu entscheiden. Dort gibt es das dateibasierte Backup in der Benutzeroberfläche als rsync Lösung.

 

[Tommes]

Warum nutzt ihr nicht ein einfaches rsync Script, wenn ihr ein dateibasiertes Backup wollt?

Mach ich ja und ich hab dafür sogar für alle hier ein Wiki geschrieben damit es jeder der möchte, nutzen kann *klick*

Ist es nicht so, dass bestehende DSM 5.2 Backup Jobs (also auch dateibasierte) in DSM 6 übernommen werden?

Ja das geht. Aber man kann "offiziell" keine neuen Backupjobs unter DSM 6 auf diese Weise anlegen. QTip hat hier aber beschreiben, wie es dennoch geht. Und eben weil es geht versteh ich nicht, warum man das nicht weiterhin "offiziell" Supporten kann.

Nur manuell, nach Tommes Anleitung...

Nö, nach QTip's Anleitung!

Tommes

 

[Puppetmaster]

Es steht jedem frei sich für QNAP zu entscheiden.

Warum der Aufwand?
Es steht jedem frei, sich gegen DSM 6.0 zu entscheiden. Auch Betriebsysteme können am Markt scheitern ;-)
So werde ich es erst einmal handhaben. Wie sich der Markt dann entwickelt, wird sich dann in der Zukunft zeigen.

 

[eddie irvine]

Langsam bin auch ich müde ob dieser Diskussion.
Also nochmal: Wieviele Endgeräte können NTFS lesen? Wieviele dagegen Synologys Hausgebräu?

Die Frage ist doch: Wie oft muss man ein Backup lesen?

Ich behaupte: Im Idealfall überhaupt nicht!
Im Fall eines Datenverlustes will ich die Datei(en) zurück spielen.
Und wenn ich das dann über die Disk Station machen muss, ist das kein Problem für mich.
Zudem stellt Synology ja auch ein Tool zur Verfügung.

 

[cmdr_tom]

Bitte sendet unbedingt Feature-Requests an Synology, dass das dateibasierte Hyperbackup wieder ermöglicht werden soll. Wenn sich genug Leute an Synology wenden, fördert das eventuell das Umdenken.

 

[Matthieu]

Call to undefined function mysql_connect()

Das scheint fast so, als ob eine DLL im PHP fehlt.

Eine DLL gibt es auf einem Linux-System eigentlich nicht, dort nennt es sich shared library. Aber davon ab: mysql_connect ist "deprecated" und sollte schnellstmöglich ersetzt werden, am besten gegen das moderne PDO. Schau auch mal in den Einstellungen vom Web Server hinsichtlich PHP-Version und Erweiterungen. Wahrscheinlich bietet die verwendete Konstellation kein mysql_connect.

MfG Matthieu

 

[QTip]

Ich frage mich, wieso die Backupdatenbank keine Checksummen oder Wiederherstellungsinformationen bildet, damit im Falle eines Falles die fehlerhaften Stellen rekonstruiert werden können. Soetwas gehört sich eigentlich, wenn man viele verschiedene Daten in einen einzigen Container kapselt. Ansonsten müsste man für die Datenbank eine Sicherung durchführen oder besser Alles gleich 2x sichern

Die Frage ist doch: Wie oft muss man ein Backup lesen?

Ich behaupte: Im Idealfall überhaupt nicht!

Normal nur selten, aber grad dann ist es nach Murphy's Gesetz nicht mehr lesbar.

 

[whitbread]

...Auch ich will ein einfaches, dateibasiertes Backup im DSM. Dann aber ein ganz schlichtes ohne Versionierung und allen anderen Schnickschnack...
...weil HB durchaus eine Daseinsberechtigung hat ...

Vorab: Also ich finde es gut, wenn hier emotional diskutiert wird, solange es nicht persönlich wird.

Ich finde HyperBackup durchaus genial und bedaure sehr, dass die Entscheidung gegen die Beibehaltung der dateibasierten Sicherung, diese (eigentlich zusätzlichen) Features in den Hintergrund drängen. Selbstverständlich geht es ausschliesslich um die Beibehaltung der bisherigen Funktionalität, also 1:1-Sicherung ohne Versionierung und Verschlüsselung eben nur bei verschlüsselten Ordnern.

Auf einen workaround mittels eigenem rsync-Script zu verweisen halte ich für zynisch, auch wenn es sicher für viele hier praktikabel wäre. Es geht doch darum, dass der Einsatz von regelmässigen Backups für alle einfach und sicher erfolgen kann. Und genau das bietet das bisherige filebasierte Backup, und ja genau das bietet HyperBackup NICHT! Warum nicht? 1. Datenbank ist nun mal anfällig für hdd Ausfälle (Backup-Dopplung machen halt nur wenige) 2. Restore nur mittels DSM oder zusätzlicher Software 3. Sicherung von gemeinsamen Ordnern nur im Zustand 'entschlüsselt' 4. Versionierung in vielen Fällen nicht notzwendig und Kenntnisse dazu kaum vorhanden; lässt Backup (ggf. unvermittelt) anwachsen 5. Nicht zu vergessen: Das Vertrauen in diese neue Lösung muss doch erst wachsen. Die Annahme, Synology würde diese nur anbieten, wenn diese sicher sei, ist imho realitätsfern.

Aber halt ich sagte ja, HyperBackup sei auch genial: Denn viele der obigen Argumente sind eben auch ein echter Vorteil: 1. Versionierung ist echt eine tolle Sache, wenn man weiss wie man es nutzen will und kann 2. Backup kann verschlüsselt werden, unabhängig von der Nutzung verschlüsselter Ordner 3. Backup kann komprimiert werden und sichert doppelte Dateien nur 1x 4. Backup kann auf bestehendes Backup aufsetzen

Ich sehe bis heute keinen Grund, die dateibasierte Sicherung zu deaktivieren. Wie man ja sieht ist die Aktivierung ein Kinderspiel, der Code somit noch vorhanden.

Im Endeffekt ist doch gerade die Nutzung beider Backup-Varianten das Mittel der Wahl: 1x Filebasierte Sicherung eben ohne Versionierung und 1x HyperBackup mit Versionierung und ggf. Verschlüsselung und/oder Komprimierung. Und ob nun das eine auf die ext. HDD und das andere auf die Backup-NAS oder vice versa könnten wir dann ja hier nochmal diskutieren...
Achja und die Möglichkeite von Snapshot und Replikation sollte man dann auch noch mit ins Spiel bringen.