Owncloud Migration – warum dauert das so lange?

 „Ich hab 10 TB in der Hosentasche – was ist euer Problem?“

So klingt es manchmal, wenn man von außen auf so eine Datenmigration schaut. Heute kann man riesige Mengen an Daten auf kleinen USB-Sticks oder Festplatten transportieren. Alles geht schnell – oder?

Nur: Das hier war keine moderne Cloud-Anwendung. Sondern eine acht Jahre alte Server-Installation mit über 2 Terabyte an Daten, die über Jahre gewachsen ist. Ein altes System mit vielen Eigenheiten, das von einer Plattform auf eine andere umziehen sollte.

Ein komplettes Neuaufsetzen war zum aktuellen Zeitpunkt nicht möglich, da die Maschine geschäftskritisch ist und keine zeitliche Lücke für einen Umstieg vorhanden war. Ja, ein Umstieg auf ein modernes System (Nextcloud, Ubuntu) ist bereits geplant – aber das wird in einem zweiten Schritt erfolgen.

Der Plan: Eigentlich ganz einfach

• Dateien vom alten Server kopieren

• auf dem neuen Server einspielen

• starten

• fertig

So dachten wir. Und so hat es auch schon oft funktioniert. Aber dieses Mal war es anders.

Was ist passiert – und warum hat es so lange gedauert?

1. Festplattenanschluss (IDE, SATA, SCSI, VirtIO)

Moderne Server verwenden schnelle virtuelle Festplattenschnittstellen wie VirtIO oder SATA. Unser altes System verstand diese aber nicht – es bootete nur, wenn die virtuelle Festplatte wie bei alten PCs über IDE eingebunden war. IDE ist aber langsam und veraltet – trotzdem mussten wir diesen Weg nehmen, damit das System überhaupt startet. Nach 3x Treiber ins System einbinden, Systemplatte kopieren, konvertieren und neu ausprobieren, konnte das Problem gelöst werdne. 

2. Fehlende Treiber (VirtIO-Treiber)

Die neuen Systeme nutzen spezielle Software, um Hardware-Zugriffe zu beschleunigen. Unser altes System kannte diese Treiber nicht und musste sie erst mühsam nachgerüstet bekommen. Vergleichbar mit einem alten Drucker, für den es auf einem neuen Computer erst mal keinen passenden Treiber gibt.

3. Speicher-Technologie (LVM Thin Pools)

Um Festplattenspeicher effizient zu verwalten, verwenden wir sogenannte Thin Pools. Die sind sparsam und flexibel – solange sie nicht überfüllt werden. Zusätzlich erfordern die Thin Pools ein Festplattenformat (RAW) und bei der Konvertierung wird der Grad der Konvertierung nicht angezeigt. Die nächste Anzeige die erfolgt ist „fertig“ nach rund 10 Stunden. In unserem Fall hat die Konvertierung über Nacht abgebrochen (ohne Fehlermeldung) und wir mussten neu starten. 

4. Netzwerkeinstellungen (MAC-Adresse, ifcfg-eth0)

Das System merkte sich die alte Netzwerkkarte (anhand ihrer eindeutigen Hardwareadresse, der MAC). Beim Umstieg auf den neuen Server bekam es aber eine neue Adresse – und das alte System blockierte die Verbindung. Erst mit manuellen Anpassungen konnten wir die Netzwerkeinstellungen wiederherstellen.

5. Größe der Datenmenge (2 TB dauern einfach)

Auch mit 10 Gbit/s Netzwerkgeschwindigkeit dauert es mehrere Stunden, 2 Terabyte Daten zu übertragen. Und wenn Konvertierungen oder Fehlerkorrekturen hinzukommen, summiert sich die Zeit.

6. Kein USB 3.0 – also keine schnelle externe Alternative

Man könnte meinen: „Dann kopiert es doch einfach auf eine USB-Festplatte und gut ist.“

Die Realität: Die betroffenen Server haben USB 2.0 Schnittstellen. Und USB 2.0 ist – freundlich gesagt – langsam. Kopierraten von unter 30 MB/s machen das Kopieren von 2 TB zur Geduldsprobe. Das ist deutlich langsamer als das Netzwerk. Eine externe Platte als schnelle Zwischenlösung war also keine Option.

Ein besonderes Thema: Formatkonvertierung der virtuellen Festplatten

Die virtuelle Maschine kam aus einer Hyper-V-Umgebung – dort werden Festplatten im sogenannten VHDX-Format gespeichert. Unser neues System (Proxmox) verwendet ein anderes Format: QCOW2 oder RAW.

Diese Konvertierung muss mit Spezialwerkzeugen wie qemu-img durchgeführt werden – und sie ist aufwendig. Allein der Konvertierungsvorgang der großen Datenplatte hat über 10 Stunden gedauert.

Und wenn – wie in unserem Fall – der Prozess abbricht, muss man von vorn beginnen. Das bedeutet: noch einmal 10 Stunden warten.

Was wir daraus gelernt haben:

• Alte Systeme lassen sich nicht einfach verschieben – sie bringen oft Altlasten mit.

• Moderne Technologien brauchen passende Vorbereitung – sonst verstehen sich die Systeme nicht.

• Einfache Migration ist ein Trugbild – besonders bei großen, alten oder komplexen Installationen.

Und jetzt?

Jetzt läuft der Server wieder. Die Daten sind da, alles funktioniert. Das System wurde erfolgreich von Hyper-V auf Proxmox übertragen.

Und ja, wir werden das System in den nächsten Wochen komplett modernisieren. Neue Basis, neues Betriebssystem, neue Software. Aber der erste Schritt war: die Verfügbarkeit wiederherstellen.

Denn wenn ein System kritisch ist, muss es laufen – auch wenn der Weg dorthin länger dauert als geplant.

Deshalb hat es so lange gedauert. Nicht, weil wir’s nicht können – sondern weil wir genau wissen, wie komplex selbst scheinbar einfache Aufgaben sein können.