Ich kam in die Verlegenheit, mein Volume1 zwecks Verkleinerung neu Aufzubauen. Bekanntlich liegen dort per default auch alle Applikationen, Optware usw, die nicht von einer Sicherung erfasst werden. Ich hatte glücklicherweise noch ein 2. Volume zur Verfügung. Dazu habe die Shared Folder und ISCSI-LUNs gesichert, auf Volume2 verschoben oder restored, das Volume1 gelöscht, mit dem reduzierten Plattenbestand neu erstellt und anschliessend wieder zurück gespielt.
Diese Erfahrungen habe ich dabei gemacht:
*Zunächst musste ich Volume2 mit einer neuen Platte erweitern. Das dauerte ca. 50h für eine SHR Ergänzung um 2TB.
*Beim Verschieben wird (leider) in jedem Verzeichnis ein zusätzliches Verzeichnis @eaDir angelegt. Das führt im Ordner "homes/<user>/.maildir" dazu, das leere Mails angezeigt werden, die man auch nicht im Mailprogram löschen kann. In var/log/messages findet sich dann ein Hinweis wie "copy: i_stream_read() failed: Is a directory". Lösung: alle Dateien/Verzeichnisse des Users root in .Maildir entfernen, da dieser keine Post bekommt : find . -user root -exec rm {} \;
*Beim Verschieben von NFSRoot-Verzeichnissen gehen die Berechtigungen auf die Devices kaputt. Da hilft nur neu anlegen. Es bootet z.B kein Rasberry mehr, weil /dev/nfs und vieles mehr nicht mehr richtig eingestellt war. Da half nur neu auf den Server kopieren
*Block-Luns lassen sich nicht verschieben. Man kann ein Backup machen und das Backup auf das andere Volume wieder einspielen. Dann wird es aber eine File-LUN mit THICK-Allocation
*File Luns mit extended Attributen lassen sich ebenfalls nicht verschieben. Auch hier funktioniert Backup und Restore, leider auch mit den gleichen Einschränkunen wie bei den Block-LUNs, das nur eine LUN mit THICK-Allocation entsteht.
*Thin File-Luns lassen sich verschieben. Beim Verschieben entsteht daraus leider auch wieder eine Thicl-LUN. Besser ist Backup und Restore, hier bleiben die Einstellungen seltsamerweise erhalten
*Bei Backup und Recovery von LUNs muss man leider jede LUN einzeln und nacheinander machen. Das dauert. Nach dem Recover stehen die LUNs als Copy jeweils mit einem neu angelegtem Target im System. Man muss also die Luns umbenennen und dem richtigen Target wieder neu zuordnen und die dann leeren Targets wieder löschen.
*Beim Restore von einzelnen Shares wurden die Berechtigungen nicht mit restored, sie mussten von Hand ergänzt werden. Restores von NFS-Verzeichnissen funktionieren nur mit standard Dateien. Links, Devices, Sockets usw. gehen gar nicht.
*Mysql-DB, Applikationen und Optware geht beim Löschen des Volume1 verloren und müssen neu installiert werden. Die psqlDB wird automatisch verlagert. Aus einem Backup konnte ich nur noch die Mysql-DB manuell zurückholen, da seltsamerweise das Backup nach dem Löschen nicht über die Gui wiederherstellbar war ("invalid Date" beim Versuch der Auswahl des Backup-Sets) . Zum Restoren einzelner Mysql-Datenbanken kann man aus dem Backup-Unterordner @app/@mysql ganz einfach die dort abgelegten sql mit mysql einspielen.
*Packages mussten alle neu installiert werden. beim Mailserver und Surveillance-Station waren bei mir die alten Einstellungen wieder verfügbar, wahrscheinlich, weil sie unter /usr/syno abgelegt werden. Keinen Erfolg hatte ich dagegen beim Logitech, Radius, DNS und DHCP-Server, dort waren alle Zonen bzw. reservierungen weg und mußten neu eingegeben werden. Beim LogitechServer konnte ich vor dem Neustart das "prefs"-Verzeichnis wieder zurückspielen und hatte dann alles so wie vorher. das muss man aber manuell vorher mit tar o.ä. selber weglegen. Das @Optware hatte ich vorher komplett getar'd. Einfach wieder auspacken, rc.optware starten, läuft. mit @appware hat das überhaupt nicht geklappt, deshalb die Packete neu installieren und leider auch in den meisten Fällen neu konfigurieren
In Summe hat mich das incl. Backup und Volumenerweiterung für ca. 4TB etwa 1 Woche gekostet. Bei Synology habe noch eine Anfrage offen, wie denn ein Austausch von Volume1 oder Disaster-Recovery incl. Packages nach deren Meinung aussehen soll. Außer Neuinstallation und Backup zurückspielen habe ich nichts gefunden. Und genau das funktionierte nicht für alle Komponenten.
Thomas
Diese Erfahrungen habe ich dabei gemacht:
*Zunächst musste ich Volume2 mit einer neuen Platte erweitern. Das dauerte ca. 50h für eine SHR Ergänzung um 2TB.
*Beim Verschieben wird (leider) in jedem Verzeichnis ein zusätzliches Verzeichnis @eaDir angelegt. Das führt im Ordner "homes/<user>/.maildir" dazu, das leere Mails angezeigt werden, die man auch nicht im Mailprogram löschen kann. In var/log/messages findet sich dann ein Hinweis wie "copy: i_stream_read() failed: Is a directory". Lösung: alle Dateien/Verzeichnisse des Users root in .Maildir entfernen, da dieser keine Post bekommt : find . -user root -exec rm {} \;
*Beim Verschieben von NFSRoot-Verzeichnissen gehen die Berechtigungen auf die Devices kaputt. Da hilft nur neu anlegen. Es bootet z.B kein Rasberry mehr, weil /dev/nfs und vieles mehr nicht mehr richtig eingestellt war. Da half nur neu auf den Server kopieren
*Block-Luns lassen sich nicht verschieben. Man kann ein Backup machen und das Backup auf das andere Volume wieder einspielen. Dann wird es aber eine File-LUN mit THICK-Allocation
*File Luns mit extended Attributen lassen sich ebenfalls nicht verschieben. Auch hier funktioniert Backup und Restore, leider auch mit den gleichen Einschränkunen wie bei den Block-LUNs, das nur eine LUN mit THICK-Allocation entsteht.
*Thin File-Luns lassen sich verschieben. Beim Verschieben entsteht daraus leider auch wieder eine Thicl-LUN. Besser ist Backup und Restore, hier bleiben die Einstellungen seltsamerweise erhalten
*Bei Backup und Recovery von LUNs muss man leider jede LUN einzeln und nacheinander machen. Das dauert. Nach dem Recover stehen die LUNs als Copy jeweils mit einem neu angelegtem Target im System. Man muss also die Luns umbenennen und dem richtigen Target wieder neu zuordnen und die dann leeren Targets wieder löschen.
*Beim Restore von einzelnen Shares wurden die Berechtigungen nicht mit restored, sie mussten von Hand ergänzt werden. Restores von NFS-Verzeichnissen funktionieren nur mit standard Dateien. Links, Devices, Sockets usw. gehen gar nicht.
*Mysql-DB, Applikationen und Optware geht beim Löschen des Volume1 verloren und müssen neu installiert werden. Die psqlDB wird automatisch verlagert. Aus einem Backup konnte ich nur noch die Mysql-DB manuell zurückholen, da seltsamerweise das Backup nach dem Löschen nicht über die Gui wiederherstellbar war ("invalid Date" beim Versuch der Auswahl des Backup-Sets) . Zum Restoren einzelner Mysql-Datenbanken kann man aus dem Backup-Unterordner @app/@mysql ganz einfach die dort abgelegten sql mit mysql einspielen.
*Packages mussten alle neu installiert werden. beim Mailserver und Surveillance-Station waren bei mir die alten Einstellungen wieder verfügbar, wahrscheinlich, weil sie unter /usr/syno abgelegt werden. Keinen Erfolg hatte ich dagegen beim Logitech, Radius, DNS und DHCP-Server, dort waren alle Zonen bzw. reservierungen weg und mußten neu eingegeben werden. Beim LogitechServer konnte ich vor dem Neustart das "prefs"-Verzeichnis wieder zurückspielen und hatte dann alles so wie vorher. das muss man aber manuell vorher mit tar o.ä. selber weglegen. Das @Optware hatte ich vorher komplett getar'd. Einfach wieder auspacken, rc.optware starten, läuft. mit @appware hat das überhaupt nicht geklappt, deshalb die Packete neu installieren und leider auch in den meisten Fällen neu konfigurieren
In Summe hat mich das incl. Backup und Volumenerweiterung für ca. 4TB etwa 1 Woche gekostet. Bei Synology habe noch eine Anfrage offen, wie denn ein Austausch von Volume1 oder Disaster-Recovery incl. Packages nach deren Meinung aussehen soll. Außer Neuinstallation und Backup zurückspielen habe ich nichts gefunden. Und genau das funktionierte nicht für alle Komponenten.
Thomas
