Vorsicht: Keine Erweiterung eines Lagacy-Volumes über 16 TB möglich

Jetzt läuft die zusätzliche Sicherung erhaltenswerter Daten des Volumes auf die 4x3TB, die im neuen TR-004 als RAID5 eingebaut sind und als externes Laufwerk angeschlossen sind. Dauert erst mal. Dann werden die MariaDB-Datenbanken gedumped, die Anmeldedaten der QmailAgent-Konten manuell (Bildschirmkopie) gesichert. Die zugehörige Datenbank lässt sich ja nicht komplett sichern, wie mir scheint.

Es ist so oder so mutig. Die RAID5-TR-004 könnte irgendwie immer „verloren“ gehen . Daher schrieb ich „zusätzliche“ Sicherung“. Alles wichtige auf diesem Volume ist bereits laufend gesichert. Da ist nur das Problem, dass es a) keine Komplettsicherung am Stück gibt und b) ich nicht am Stück einige Tage das durchziehen kann. Sichere ich einen Bereich, ändern sich in der Zeit Daten im anderen Teil. Das gilt es zu optimieren.

Man kann vom Legacy keinen Snapshot erstellen.

Gerade denke ich über den Tipp nach, das komplette Verzeichnis MD0_DATA zu speichern und nachher im neuen Volume wieder einzuspielen, dann die Verzeichnisnamen in /etc/config/qpkg.config anpassen. Ob dann alles wieder so ist wie es war????

Die Überlegung: statisch/thick/thin hat sich jetzt erst mal soweit einen Schritt geklärt, dass das Systemvolume einer der Typen statisch oder thick sein muss. Weiter halte ich es jetzt doch nicht für wirklich sinnvoll, das riesige RAID5 komplett als Systemvolume zu definieren. Folglich wird es nun doch auf erst mal ein thick hinauslaufen für das System.

Manche Verknüpfungen sind hier ja schon dubios. Ich wundere mich, warum die Sicherung von /share/MD1_DATA/.qpkg ewig dauert, bis ich feststellte, dass im Unterverzeichnis CodexPack irgendwo ein Link zu externen Laufwerken zu existieren scheint und die Sicherung gleich meine online gesicherten Fotos mit kopieren will. So ganz verstehe ich das nicht. Hab jetzt einfach mal CodexPack deinstalliert und die Sicherung ist schnell durch.

So, im Großen und Ganzem ist der Umstieg ohne Schwierigkeiten gelaufen. Klar, Details die die MariaDB-Datenbanken habe ich vorher gesichert und dann manuell wieder eingespielt. Aber erstaunlicherweise hat beispielswiese QmailAgent ohne viel Schwierigkeiten den Umstieg mitgemacht. Die Daten mussten an die richtige Stelle kopiert werden und die Pfade/Links teilweise einzeln ersetzt werden. Logitechmediaplayer musste ich beenden und neu starten, dann war auch wieder alles in Ordnung.

Jetzt fehlen noch Feinarbeiten an den persönlichen Ordnern und natürlich muss die neue Struktur muss in den Apps angepasst werden. Qsync beispielsweise will noch nicht so wie ich. Dann will ich die großen Bereiche wie Multimedia und Public nicht im Standard-Volume 1 ablegen sondern ein eigenes Volume dafür jeweils.

Muss hier ein ausdrückliches Lob an den Support aussprechen.

Bin leider gerade über ein dickes Problem gestolpert: Qmail bzw QmailAgent funktioniert doch nicht so wie ich zuerst gemeint hatte. Trotz gutem Willen muss ich jetzt leider einsehen, dass der Support doch nicht so genau bescheid wusste, was dies betrifft. Alle anderen Apps wie Twonky, TVHeadend Plex scheinen weitestgehend zu funktionieren.

Qmail und QmailAgent scheine zwei verschiedene paar Stiefel zu sein. Qmail holt die Mails ordentlich ab und legt sie in eine eigene Datenbank ab. In QmailAgent kann ich auch schon die Liste der Mails sehen. Das hatte mich auch in die Irre geleitet. Ich sehe zwar die Liste mit alten und neuen Mails, aber öffnen kann ich sie dann nicht.

Gehe ich in das Verzeichnis auf dem NAS, auf dem die lokal gespeicheten Mails abgelegt werden, kann ich diese in File Station auch öffnen und ansehen.

Kurz und gut: Empfehlen kann ich einen solchen Umzug der Mails bisher nicht. Ich suche nach wie vor den Knoten, um die Mails auch in QmailAgent sehen zu können. Gilt natürlich auch für den mobilen Zugriff. Irgendwas habe ich da noch falsch gemacht. Bin halt leider auch nicht so der Experte....

Zum Blogbeitrag: Da ich selber leider immer nur sporadisch an die Sache komme und jedesmal wieder rätseln muss, was ich den letztes Mal gemacht habe, wird as wohl leider erst mal nichts. Danke für das Vertrauen.

Schon richtig, ganz so krass meinte ich das auch nicht. Dennoch, im Moment fehlt mir absolut der Ansatz für die Lösung.

EDIT: Lasst mir etwas Zeit, dann fasse ich das wesentliche nochmal richtig zusammen.

Jetzt muss ich das ganze dann wirklich mal zusammenschreiben.

Nachdem ich nun das Problem endlich eingekreist und auch den entscheidenden Fehler ausmachen konnte, ist mir jetzt auch ein Workaround gelungen.

Ich werde das hier mal in kurzen Worten zusammenfassen, auch wenn es nicht wirklich zu Thema passt. Wie gesagt, eine ausführliche Dokumentation des kompletten Umstiegs habe ich noch vor, muss aber dann auch die Zeit haben.

Mein letztes Problem war, dass QmailAgent zwar an sich lief, auch die Zugangsdaten der angelegten Postfächer funktionierte, die Mails alle wieder eingesammelt aud auf dem NAS lokal abgelegt wurden, sie aber leider innerhalb QmailAgent im Browser und auch an den Mobilgeräten (Android und Iphone) deren Inhalt nicht gezeigt wurde. Sie wurden alle schön gelistet, aber eben nicht gezeigt. Hingegen konnte ich sie aus File Station heraus aus ihrem lokalen Speirort heraus mit QmailAgent öffnen und anzeigen.

Wenn man weiß, wo man suchen muss, ist die Lösung oft einfach und scheint naheliegend. So auch hier: In den Logfiles zu den einzelnen Postfächern (sogar direkt aus QmailAgent gesammelt herunterladbar und einfach am PC einzusehen) stand der Fehler: Irgendwo wurde weiterhin auf die alte Verzeichnisstruktur zugegriffen, und das wohl sowohl für alte Mails als auch für neue. Das liegt ganz sicher daran, dass ich eben die komplette Struktur von QmailAgent aus der alten Installation übernehmen wollte, um eben alle Postfächer und auch alten Mails wieder zu haben.

Dazu hatte ich zuerst auf das neue Volume1 sowohl das komplette Verzeichnis der Freigabe QmailAgent aus dem alten MD1_DATA sowie qmail aus dem alten .qpkg kopiert, die darin auftretenden Verlinkungen in mailstore auf die entsprechenden Unterverzeichnisse aus QmailAgent neu angelegt und erst anschließend QmailAgent aus dem Appstore ganz neu installiert.

Wo der Zugriff auf die alte Struktur dennoch stattfand lies sich per Linux-Kommando 'grep' ausfindig machen: Diese Verknüpfung liegt innerhalb der QmailAgent-internen Datenbank in

/mnt/ext/opt/qmail/var/data/ibdata1

Natürlich bin ich jetzt auch der naheliegenden Verführung erlegen, in diesem File nun einfach alle Einträge der alten Struktur auf die neue per Linux-Befehl 'sed' auszutauschen - hat aber dann gar nicht mehr funktioniert.

Also nun endlich der Workaround:

1. Unter /share habe ich ein neues Verzeichnis MD1_DATA angelegt.

2 Darunter dann den Link anlegen:

ln -s /share/QmailAgent /share/MD1_DATA/QmailAgent

Und voílà: Sowohl im Browser als auch in den mobilen Devices sind die Mails wieder sichtbar.

Noch ein Hinweis: Der Trick mit dem symbolischen Link hilft auch bei anderen Anwendungen. Beispielsweise hatte ich zwar alle meine VMs vor dem Umzug exportiert nd einzeln gesichert, dennoch hatte ich den Wunsch, dass ich sie auch nach dem Umzug wieder direkt zum Laufen bringe und nicht durch den neuen Import erst wieder im alten Zustand habe. Die wichtigste davon war sofort wieder lauffähig, da ich sie auf einem anderen Datenträger installiert hatte mit allen ihren Laufwerken. Sehr einfache VMs wie beispielsweise eine Minimal-Debian-Version für FHEM brachte ich einfach durch das Auswählen der neuen Position des IMG in Virtualization Station wieder sofort zum laufen. Das funktionierte allerdings bei den meisten VMs dann doch nicht mit dem Hinweis wegen eingebundener Snapshots. Mein Ubuntu hatte ich dann doch gelöscht und anschließend wieder importiert. Bei allen anderen wollte ich das dann doch nicht machen müssen.

Es hat dann aber sofort funktioniert, als ich die neue Position der alten IMGs auf einen Namen verlinkt habe, der der alten Position entsprach. Alle VMs waren danach ohne irgendein Neustart wieder lauffähig.