Von Synology auf UGREEN NAS umziehen: Daten, Rechte, Docker

Wer von einer Synology auf eine UGREEN NAS umsteigt, möchte die Daten vollständig mitnehmen: Freigaben, Fotos, Dokumente und oft auch die Daten laufender Docker-Container. Bei mehreren Terabyte ist rsync über SSH der zuverlässigste Weg. Dabei gibt es drei Stolperstellen: die Rechte von UGOS, ein Sonderverhalten des rsync auf der Synology und die Rechte der Container-Daten. Diese Anleitung zeigt Schritt für Schritt den Umzug mit Prüfung.

Grundlage ist ein echter Umzug von einer Synology DS920+ auf eine UGREEN DXP4800 Pro mit UGOS Pro 1.21.0.0190. Namen, Adressen und Konten sind in den Beispielen ersetzt.

Voraussetzungen

• Synology mit DSM 7 und eine eingerichtete UGREEN NAS, beide im selben Netz, am besten per Kabel
• Auf beiden Geräten ein Konto mit Administratorrechten
• SSH auf beiden Geräten aktiviert, für die UGREEN siehe Teil 52
• Genug freier Platz auf der UGREEN, mit Reserve für Snapshots
• Eine aktuelle Sicherung der Synology, bevor Sie beginnen
• Zeit: etwa eine Stunde Vorbereitung, dazu die Kopierdauer, bei 1 Gbit/s grob drei Stunden je Terabyte

Schritt 1: Platz und Ziel auf der UGREEN prüfen

Öffnen Sie auf der UGREEN die App Speicher und sehen Sie sich die Übersicht an. Alle Laufwerke sollten den Status Normal zeigen, bevor Sie viele Terabyte darauf schreiben.

Vergleichen Sie den freien Platz der Speicherpools mit der belegten Menge auf der Synology. Rechnen Sie mindestens 20 Prozent Reserve ein.

Verifizieren: Alle Laufwerke zeigen Normal, und der freie Platz reicht für die Daten der Synology plus Reserve.

Schritt 2: Die Freigaben auf der UGREEN anlegen

Legen Sie jeden Zielordner zuerst als freigegebenen Ordner in der Oberfläche an, nicht per Terminal. Nur so erhält er die Rechte von UGOS, die Sie in der App Dateien verwalten. Wie das geht, zeigt Teil 25.

Übernehmen Sie die Namen der Synology, wenn Programme und Skripte die Pfade kennen, etwa Daten oder Download. Vergeben Sie die Rechte gleich jetzt, so wie sie später gelten sollen, siehe Teil 26. Bei UGOS regeln diese Rechte den Zugriff, sie stehen als eigenes Attribut am Ordner. Dateien, die später in den Ordner kopiert werden, erben die Rechte, solange die Kopie keine eigenen Rechte mitbringt.

Für Docker legen Sie keine neuen Freigaben an. Die Container-Daten kommen in den Ordner docker, den UGOS beim Einrichten von Docker anlegt, oder in einen Unterordner davon.

Verifizieren: Alle Zielordner erscheinen in der Liste der freigegebenen Ordner auf dem gewünschten Volume.

Schritt 3: SSH vorbereiten und die Verbindung testen

Die Kopie läuft auf der UGREEN: Sie holt die Daten von der Synology ab. So schreibt das Gerät, auf dem die Daten künftig liegen, selbst in seine Ordner. Aktivieren Sie auf der UGREEN in der Systemsteuerung unter Terminal den SSH-Dienst.

Aktivieren Sie auf der Synology in DSM ebenfalls SSH, unter Systemsteuerung, Terminal und SNMP. Zusätzlich braucht die Synology eine Einstellung, die leicht übersehen wird: Das rsync von DSM prüft, welcher DSM-Benutzer es aufruft, und lehnt Benutzer ohne rsync-Berechtigung ab. Bei uns lieferte ein Aufruf über sudo die Meldung „user has disabled/expired“ mit Code 44, weil root kein DSM-Benutzer mit dieser Berechtigung ist. Gehen Sie deshalb so vor:

• In DSM unter Systemsteuerung, Dateidienste, rsync den rsync-Dienst aktivieren
• Unter Systemsteuerung, Benutzer und Gruppe, das Kopierkonto bearbeiten und im Reiter Anwendungen rsync erlauben
• Dem Kopierkonto Leserechte auf alle Freigaben geben, die umziehen
• Das Kopierkonto in die Gruppe administrators aufnehmen, denn nur diese Konten dürfen sich in DSM per SSH anmelden
• Unter Benutzer und Gruppe, Erweitert, den Benutzer-Home-Dienst aktivieren, sonst findet SSH den Schlüssel des Kontos nicht
• Verschlüsselte Freigaben vor der Kopie einhängen

Die Kopie läuft später als root auf der UGREEN. Erzeugen Sie den SSH-Schlüssel deshalb ebenfalls als root:

sudo -i
ssh-keygen -t ed25519 -f /root/.ssh/umzug -N ""
cat /root/.ssh/umzug.pub

Tragen Sie die ausgegebene Zeile auf der Synology in die Datei ~/.ssh/authorized_keys des Kopierkontos ein und setzen Sie dort die Rechte, die SSH verlangt:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Testen Sie dann auf der UGREEN, weiterhin als root:

ssh -i /root/.ssh/umzug umzug@synology.local "ls /volume1"

Ersetzen Sie umzug durch Ihr Kopierkonto und synology.local durch Name oder Adresse Ihrer Synology. Läuft SSH auf der Synology auf einem eigenen Port, gehört er in die SSH-Option: bei ssh als -p 2222, bei rsync als -e "ssh -p 2222 -i /root/.ssh/umzug". Setzen Sie -p nie direkt hinter rsync, dort bedeutet es „Rechte übernehmen“.

Verifizieren: Der Befehl zeigt als root ohne Passwortabfrage die Freigaben der Synology an.

Schritt 4: Die Freigaben mit rsync kopieren

Kopieren Sie nur Inhalt, Zeitstempel, Verknüpfungen und Hardlinks. Ein Beispiel für die Freigabe Daten, ausgeführt als root auf der UGREEN:

sudo -i
rsync -e "ssh -i /root/.ssh/umzug" -rltHW --partial --info=progress2,stats2 \
  --exclude='@eaDir' --exclude='#recycle' --exclude='#snapshot' --exclude='@tmp' \
  --exclude='.DS_Store' --exclude='Thumbs.db' \
  umzug@synology.local:/volume1/Daten/ /volume1/Daten/

Was die Optionen bedeuten:

• -r -l -t: Ordner rekursiv, Verknüpfungen als Verknüpfungen, Zeitstempel erhalten
• -H: Hardlinks bleiben Hardlinks und belegen keinen doppelten Platz
• -W: ganze Dateien übertragen, im lokalen Netz schneller als der Abgleich von Blöcken
• --partial: angefangene Dateien nicht löschen. Mit -W überträgt rsync eine abgebrochene Datei beim nächsten Lauf neu, fertige Dateien überspringt es
• --exclude: Vorschaubilder und Metadaten der Synology (@eaDir), ihren Papierkorb (#recycle), den Ordner #snapshot, falls die Synology Snapshots sichtbar macht, Zwischendateien (@tmp) und die Begleitdateien von macOS und Windows weglassen

Bewusst fehlen -p, -o, -g und -a. So bringt rsync keine Rechte mit, und der Inhalt erbt die Rechte der Freigabe, genau wie Dateien, die Sie per SMB anlegen. Achten Sie auf die Schrägstriche am Ende beider Pfade: Sie kopieren den Inhalt in den Ordner, nicht den Ordner in den Ordner.

Starten Sie lange Läufe so, dass ein geschlossenes Terminal sie nicht abbricht, zum Beispiel mit systemd-run --unit=umzug-daten vor dem rsync-Befehl. Den Fortschritt sehen Sie mit journalctl -u umzug-daten -f. Bricht die Verbindung ab, beendet rsync sich mit einem Fehlercode, bei Netz- und SSH-Abbrüchen meist 12 oder 255. Starten Sie denselben Befehl einfach erneut: rsync überspringt Fertiges und setzt fort. Code 24 bedeutet, dass Dateien während der Kopie verschwunden sind, das ist unkritisch, wenn auf der Synology noch gearbeitet wird.

Bei unserem Umzug kamen 4,17 TB in 12 Stunden 52 Minuten an, im Schnitt 90 MB/s über ein Gigabit-Netz. Die 750 Dateien mit Hardlinks blieben mit -H Hardlinks.

Verifizieren: rsync endet mit einer Zusammenfassung ohne „rsync error“, und die Ordner erscheinen in der App Dateien.

Schritt 5: Besitzer setzen, Rechte nicht anfassen

Das rsync von UGOS setzt beim Kopieren keine Besitzer, auch nicht mit -o oder --chown. Die kopierten Dateien gehören deshalb root. Für den Zugriff spielt der Besitzer keine Rolle, auch nicht für Container. Setzen Sie ihn trotzdem, damit alte und neue Dateien einheitlich aussehen. Brauchen Container wie ein Medienserver Zugriff auf eine Freigabe, geben Sie in der App Dateien der Gruppe users Lese- oder Schreibrechte auf diese Freigabe und starten den Container mit PUID=1000 und PGID=100. Ermitteln Sie die IDs Ihres Kontos:

id IhrKonto

Setzen Sie dann den Besitzer auf den Inhalt der Freigabe, bei uns 1000:10 für das erste Administratorkonto und die Gruppe admin:

find /volume1/Daten -mindepth 1 -path '/volume1/Daten/#recycle' -prune -o -exec chown -h 1000:10 {} +

Verwenden Sie dabei kein chmod auf die Freigaben. In unserem Test entfernte chmod auf einem Ordner dessen Rechte von UGOS, der Ordner lief danach mit klassischen Linux-Rechten. chown dagegen ließ die Rechte von UGOS stehen. Wie die Vererbung bei UGOS funktioniert, erklärt Teil 27.

Verifizieren: Melden Sie sich mit einem Testkonto per SMB an. Es sieht nur die Ordner, die es sehen darf, und ein gesperrter Unterordner bleibt gesperrt.

Schritt 6: Alternative ohne Terminal mit Sync & Backup

Die App Sync & Backup kann Daten ebenfalls von der Synology abholen. Das ist allerdings eine Sicherungsaufgabe und kein Kopierjob. Legen Sie eine neue Sicherungsaufgabe an und wählen Sie den Typ Server sichern.

Im nächsten Dialog wählen Sie den Server-Typ und tragen Adresse und Zugang der Synology ein.

Für rsync muss auf der Synology der rsync-Dienst laufen, ohne Übertragungsverschlüsselung auf Port 873, mit einem Konto mit rsync-Berechtigung. Sie haben auf diesem Weg weniger Einfluss auf Ausschlüsse und Prüfläufe als im Terminal, für den eigentlichen Umzug haben wir deshalb rsync im Terminal verwendet. Wenn Sie Sync & Backup nutzen möchten, probieren Sie es zuerst an einem kleinen Ordner. Mehr zu den Sicherungsaufgaben steht in Teil 53.

Verifizieren: Beim Probeordner liegen die Daten als normale Dateien auf der UGREEN, und ein Testkonto hat darauf genau die Rechte der Zielfreigabe.

Schritt 7: Docker-Daten mit tar umziehen

Container-Daten brauchen eine andere Behandlung als Freigaben. Hier zählen Besitzer und Rechte, denn eine Datenbank läuft oft unter einer eigenen Benutzer-ID und startet nur mit den erwarteten Rechten. Das rsync der UGREEN setzt keine Besitzer, deshalb kopieren Sie diese Ordner mit tar. Halten Sie den Container auf der Synology vorher an, damit die Daten in sich stimmig sind. Dann auf der UGREEN als root (sudo -i):

mkdir -p /volume2/docker/import/app
ssh -i /root/.ssh/umzug umzug@synology.local "sudo -n /bin/tar --numeric-owner -cf - -C /volume1/docker/app ." \
  | tar -x --numeric-owner -p --exclude='@eaDir' -f - -C /volume2/docker/import/app

--numeric-owner überträgt die Benutzer-IDs als Zahl, unabhängig davon, wie die Konten auf beiden Geräten heißen. -p erhält die Rechte. Damit sudo auf der Synology ohne Passwortabfrage läuft, braucht das Kopierkonto für genau diesen tar-Befehl eine Freigabe in einer Datei unter /etc/sudoers.d auf der Synology. Die Zeile muss genau dem Aufruf entsprechen:

umzug ALL=(root) NOPASSWD: /bin/tar --numeric-owner -cf - -C /volume1/docker/app .

Legen Sie für jeden Ordner eine eigene Zeile an und löschen Sie die Datei nach dem Umzug wieder.

Ein Befund aus unserem Umzug: Die per tar kopierten Ordner brachten Rechte-Einträge der Synology mit, zum Beispiel für die Benutzer-ID 1026, die es auf der UGREEN nicht gibt. Entfernen Sie die Einträge je Stack mit ugacltool del_all und dem Ordner als Ziel, und setzen Sie danach Besitzer und Rechte mit chown und chmod so, wie der Container sie erwartet. chmod allein entfernte die Einträge bei uns nicht zuverlässig. Wenden Sie das nur auf Container-Ordner an, nie auf Freigaben. Beim offiziellen Postgres-Image auf Debian-Basis etwa gehört der Datenordner der ID 999 und verlangt die Rechte 700, die Alpine-Variante nutzt die ID 70. Sonst starten Container mit falschen Rechten oder verweigern den Start. Den Aufbau der Stacks auf Debian-Basis beschreibt Docker Compose als Grundlage.

Verifizieren: Jeder Container startet auf der UGREEN, die Protokolle zeigen keine Fehler wie „permission denied“, und die Anwendung zeigt die alten Daten.

Schritt 8: Den Umzug prüfen

Bevor Sie die Synology abschalten, prüfen Sie, ob alles angekommen ist. Der zuverlässigste Test ist ein Probelauf von rsync mit -n:

rsync -e "ssh -i /root/.ssh/umzug" -rltH -n --stats \
  --exclude='@eaDir' --exclude='#recycle' --exclude='#snapshot' --exclude='@tmp' \
  --exclude='.DS_Store' --exclude='Thumbs.db' \
  umzug@synology.local:/volume1/Daten/ /volume1/Daten/

In der Ausgabe steht die Zeile „Number of regular files transferred“. Zeigt sie 0, ist jede Datei der Synology mit gleicher Größe und gleichem Zeitstempel auf der UGREEN vorhanden. Die Zeile „Number of files“ nennt hinter reg die Zahl der Dateien, die rsync ohne die Ausschlüsse kopieren würde. Vergleichen Sie sie mit der Zahl auf der UGREEN:

find /volume1/Daten -path '/volume1/Daten/#recycle' -prune -o -type f -print | wc -l

Für die Docker-Ordner lesen Sie die Quelle mit demselben tar-Befehl noch einmal und zählen nur die Einträge:

ssh -i /root/.ssh/umzug umzug@synology.local "sudo -n /bin/tar --numeric-owner -cf - -C /volume1/docker/app ." \
  | tar -tv --numeric-owner -f - | wc -l
find /volume2/docker/import/app | wc -l
find /volume2/docker/import/app -printf '%U:%G\n' | sort | uniq -c

Die ersten beiden Zahlen sollten gleich sein, die dritte Ausgabe zeigt die Besitzer im Ziel.

Verifizieren: Der Probelauf meldet 0 übertragene Dateien, und die Zahl hinter reg stimmt mit der Zählung auf der UGREEN überein.

Schritt 9: Abgleich am Ende und Umschalten

Bis zum Umschalten kommen auf der Synology neue Dateien dazu. Planen Sie deshalb einen letzten Abgleich: Halten Sie Dienste und Container auf der Synology an, stellen Sie die Clients auf Pause und starten Sie denselben rsync-Befehl wie in Schritt 4 noch einmal. Er überträgt nur, was sich geändert hat, und ist meist in Minuten fertig. Danach setzen Sie den Besitzer für neue Dateien, schneller nur für abweichende Einträge:

find /volume1/Daten -mindepth 1 -path '/volume1/Daten/#recycle' -prune -o \( ! -uid 1000 -o ! -gid 10 \) -exec chown -h 1000:10 {} +

Docker-Daten kopieren Sie beim Umschalten mit angehaltenem Container noch einmal mit tar, immer in einen leeren Ordner und nie über eine frühere Kopie. Sonst bleiben alte Datenbankdateien wie -wal oder -shm von SQLite liegen und können die Datenbank beschädigen.

Verwenden Sie dabei kein --delete. Gelöschte Dateien auf der Synology bleiben so auf der UGREEN erhalten, und ein Tippfehler im Pfad löscht nichts. Dateien, die Sie seit der ersten Kopie auf der Synology umbenannt oder verschoben haben, liegen danach doppelt. Räumen Sie diese nach dem Umzug in Ruhe auf.

Stellen Sie danach die Clients um: Netzlaufwerke unter Windows (Teil 33), den Finder am Mac (Teil 34), Time Machine (Teil 59) und Ihre Sicherungen. Räumen Sie danach auf der Synology auf: Datei unter /etc/sudoers.d löschen, den Schlüssel aus authorized_keys entfernen, den rsync-Dienst und die rsync-Berechtigung des Kopierkontos abschalten. Lassen Sie die Synology einige Wochen unverändert stehen, bevor Sie sie löschen oder verkaufen.

Verifizieren: Alle Clients arbeiten mit der UGREEN, und eine erste Sicherung der neuen NAS ist gelaufen.

Typische Fehler

• „user has disabled/expired“, Code 44: Das rsync der Synology lehnt den Aufruf ab. Dem Kopierkonto fehlt die Anwendungsberechtigung rsync, oder rsync läuft auf der Synology über sudo. Berechtigung in DSM erteilen und ohne sudo kopieren.
• Ein Testkonto sieht plötzlich gesperrte Ordner: Die Kopie hat Rechte mitgebracht, oder jemand hat chmod verwendet. Rechte in der App Dateien neu setzen und künftig ohne -p und ohne chmod auf Freigaben arbeiten.

Häufige Fragen

Warum nicht einfach rsync -a?

-a enthält -p, -o und -g. Mit -p setzt rsync die Rechte der Synology per chmod, und chmod entfernt bei UGOS das Rechte-Attribut. Die Dateien laufen dann mit den Linux-Rechten der Synology statt mit den Rechten der Freigabe. Ohne -p erben sie die Rechte der Freigabe. Mehr zu rsync und den Rechten von UGOS steht in Teil 57.

Was passiert mit den Snapshots der Synology?

Die Snapshots der Synology lassen sich nicht in UGOS übernehmen, kopiert wird nur der aktuelle Stand. Richten Sie auf der UGREEN neue Snapshots ein, siehe Teil 21.

Fazit

Lassen Sie die UGREEN die Daten selbst abholen, kopieren Sie Freigaben ohne Rechte und setzen Sie danach nur den Besitzer. Container-Daten kommen mit tar und bekommen ihre Rechte je Stack neu. Ein Probelauf mit rsync -n und ein letzter Abgleich vor dem Umschalten sorgen dafür, dass nichts fehlt.

Weiterführende Anleitungen und Quellen

• Teil 52: SSH einrichten
• Teil 57: NAS zu NAS mit rsync
• Teil 61: Docker-Daten sichern
• Teil 62: Wiederherstellung testen
• UGREEN: rsync-Dienst
• rsync-Handbuch