🌐 Auch auf: English · Français · Español
(Dieser Artikel ist die logische Fortsetzung des hier beschriebenen Backup-Skripts: Nextcloud Backup Like a Pro – Automated with Bash. Beide Beiträge gehören zusammen und ergeben den kompletten Workflow für Migration und Disaster Recovery.)
Nach einigen Jahren mit einer treuen Nextcloud-Instanz – samt unzähligen Nutzerdateien, Kalendern, Kontakten und skurrilen geteilten Ordnern – war ein Upgrade fällig. Der alte Server zeigte erste Alterserscheinungen, und eine glänzende neue Maschine war bereits mit Ansible für einen sauberen Neustart aufgesetzt.
Statt mit manuellen Exporten, wackeligen Web-GUIs oder browserbasierten Backup-Plugins herumzufummeln, habe ich mich für ein schlankes, kompromissloses Bash-Skript entschieden, das die komplette Migration übernimmt. Damit konnte ich den ganzen Nextcloud-Stack (Core-Dateien, Nutzerdaten und Datenbank) auf den neuen Server umziehen – reproduzierbar und mit minimaler Downtime.
🧠 Was dieses Skript macht
- Stoppt Dienste sauber auf dem Zielserver, um Dateisperren und Konflikte zu vermeiden.
- Synchronisiert die Nextcloud-Anwendungsdateien (ohne das Verzeichnis
data/). - Überträgt die Nutzerdaten separat an ihren neuen Zielpfad.
- Stellt die Datenbank wieder her aus einem lokalen Dump, mit
scpundmysql. - Korrigiert Besitzer und Rechte, damit der Webserver zugreifen kann.
- Startet PHP und die Webdienste neu, sobald alles an seinem Platz ist.
- Bestätigt den Abschluss mit einer finalen Statusmeldung.
📁 Hinweise zur Verzeichnisstruktur
Im Zuge der Migration haben wir außerdem das Verzeichnis data/ verlegt – an einen eigenen Ort außerhalb des Apache-Webroots. Das ist sauberer und sicherer, als die Nutzerdaten im Hauptinstallationsverzeichnis von Nextcloud abzulegen (so war es vorher).
Das Skript berücksichtigt diese Änderung, indem es den Ordner data/ separat überträgt und ihn auf dem Zielserver an seinem neuen, externen Ort ablegt.
⚙️ Das Migrationsskript
#!/bin/bash
# === CONFIGURATION ===
REMOTE_USER="root"
REMOTE_HOST="your.remote.ip"
REMOTE_SSH_PORT=22
SSH_KEY="$HOME/.ssh/id_rsa"
BACKUP_DIR="/data/backup/nextcloud/instance-a"
REMOTE_NEXTCLOUD_DIR="/var/www/html/nextcloud"
REMOTE_DATA_DIR="/data"
DB_NAME="your.db.name"
DB_USER="your.user"
DB_PASS="********" # 🔐 Password removed for security
WWW_USER="www-data"
SSH_CMD="ssh -i $SSH_KEY -p $REMOTE_SSH_PORT -o LogLevel=ERROR $REMOTE_USER@$REMOTE_HOST"
echo "🛑 [1/7] Stopping remote web and PHP services ..."
$SSH_CMD "systemctl stop apache2 2>/dev/null || systemctl stop httpd 2>/dev/null"
$SSH_CMD "systemctl stop php8.2-fpm 2>/dev/null || true"
echo "📤 [2/7] Transferring Nextcloud files (excluding data/) to remote server ..."
rsync -a --delete --exclude "data/" \
-e "ssh -i $SSH_KEY -p $REMOTE_SSH_PORT -o LogLevel=ERROR" \
"$BACKUP_DIR/nextcloud/" "$REMOTE_USER@$REMOTE_HOST:$REMOTE_NEXTCLOUD_DIR/"
echo "📤 [3/7] Transferring user data (nextcloud/data/) to remote /data ..."
rsync -a --delete \
-e "ssh -i $SSH_KEY -p $REMOTE_SSH_PORT -o LogLevel=ERROR" \
"$BACKUP_DIR/nextcloud/data/" "$REMOTE_USER@$REMOTE_HOST:$REMOTE_DATA_DIR/"
echo "🛢️ [4/7] Transferring and restoring database dump ..."
scp -i "$SSH_KEY" -P $REMOTE_SSH_PORT "$BACKUP_DIR/db.sql" "$REMOTE_USER@$REMOTE_HOST:/tmp/db.sql"
$SSH_CMD "mysql -u '$DB_USER' -p'********' '$DB_NAME' < /tmp/db.sql && rm /tmp/db.sql" echo "🔒 [5/7] Setting remote file permissions ..." $SSH_CMD "chown -R '$WWW_USER:$WWW_USER' '$REMOTE_NEXTCLOUD_DIR'" $SSH_CMD "chown -R '$WWW_USER:$WWW_USER' '$REMOTE_DATA_DIR'" echo "🚀 [6/7] Starting remote services ..." $SSH_CMD "systemctl start php8.2-fpm 2>/dev/null || true"
$SSH_CMD "systemctl start apache2 2>/dev/null || systemctl start httpd 2>/dev/null"
echo "✅ [7/7] Remote restore complete. Please verify your Nextcloud instance at: https://$REMOTE_HOST"
🎉 Fazit
Eine produktive Nextcloud-Instanz umzuziehen, die schon seit Jahren läuft – mit echten Daten und echten Nutzern –, kann einschüchternd sein. Mit einem strukturierten Vorgehen und ordentlicher Automatisierung muss es das aber nicht. Dank dieses Skripts und einer sauberen, per Ansible aufgebauten Zielumgebung dauerte der ganze Vorgang keine 30 Minuten und kam ohne jedes manuelle Nachjustieren aus. Nerdherz, was willst du mehr.
Wenn du selbst eine Nextcloud-Migration planst, vor allem mit großen Datenmengen und null Toleranz für menschliche Fehler, probier diesen Ansatz aus – und pass ihn an deinen Infrastruktur-Stil an.
