Server parallel neu aufsetzen

Ich habe das bisher genauso wie du gemacht, auch weil ich damit gleich auf modernere Hardware umsteige.
In Zukunft werde ich es aber auch so machen, wie du es geplant hast.
Ich habe schon oft Server gespiegelt, allerdings nicht über Image, sondern mit rsync. Das bisher immer gut geklappt.

Ich nehme an, Du meinst die Image-Funktionalität im SCP?

Die Idee mit dem Image Backup könnte zu einem Problem werden, falls die Festplatten unterschiedliche Größen haben (wovon auszugehen ist bei gen 9.5/12.5.) Vom kleineren Storage auf den größeren hast Du kein Problem (außer nicht genutzter Speicherplatz), aber in die andere Richtung wirds ggf. problematisch..

Daher ist der rsync vermutlich eine bessere Idee, wobei man das vermutlich im Rettungssystem machen sollte, sonst kann es manchmal komische Fehlermeldungen/Warnungen wegen device files geben.

Wie ich das mal gemacht habe in einer ähnlichen Situation (Umzug zwischen zwei Hostern, aber verschlüsselte Partitionen): auf dem Zielsystem Partitionen genauso angelegt wie auf dem Quellsystem und dann mit dd die einzelnen Partitionen (EFI, boot, daten) im Rettungssystem kopiert. Klappt natürlich nur, wenn dein teurer temporärer Server nicht weniger Plattenplatz hat als der aktuelle.

Sowohl im rsync als auch im dd Fall nicht vergessen, dass ggf. die Netzwerkkonfiguration im Rettungssystem nach dem Kopieren angepasst werden muss.

rsync Grundgerüst:
https://wiki.archlinux.org/title/Rsync#Full_system_backup
Als Quelle oder Ziel dann in deinem Fall per SSH den anderen Server angeben.
+ einige Nacharbeiten, fstab, uuid, bootloader, ip adressen... usw

Ggf. postete dir hier jemand noch den Link zu einer fertigen Anleitung auf Deutsch für dein OS

Zitat von SiebenG

....wobei man das vermutlich im Rettungssystem machen sollte...

Auf jeden Fall!

Und rsync von einer größern Platte zu einer kleineren ist gar kein Problem. Bei einem snapshot würde das definitiv scheitern.

Zitat von SiebenG

Sowohl im rsync als auch im dd Fall nicht vergessen, dass ggf. die Netzwerkkonfiguration im Rettungssystem nach dem Kopieren angepasst werden muss.

Ich habe es auch schon so gemacht, dass ich zunächst auf dem Zielserver das gleiche OS installiert habe und dann beim rsync bestimmte Verzeichnisse ausgeschlossen habe. (z.B. /etc/netplan)

Wenn du viel Zeit und Muße hast, kannst du natürlich auch einfach den alten Server dann auch nochmal ganz neu aufsetzten und dabei die Fehler korrigieren, die du beim Aufsetzen des neuen gemacht hast.

Alternativ ist so eine Migration/Rebuild auch ein guter Zeitpunkt das Backup Konzept zu testen.

"Oh nein! Mein alter Server ist tot! Ich muss das Backup jetzt auf einem neuen Server restoren!"
Wenn es nicht klappt? Dann solltest du dein Backup überarbeiten.

Wenn es klappt? herzlichen Glückwunsch! Dein backup klappt und du hast erfolgreich einen Restore Test gefahren.

Dann lässt du es auf dem neuen Server laufen, kümmerst dich um deinen alten (neu aufbauen u.s.w.) und machst einen Restore auf den alten Server zurück.

Ja, das ist eine gute Idee und die zusätzliche Zeit ist m.E. gut investiert.

So und nicht anders habe ich meine Nextcloud von daheim auf einen Server hier migriert.

Mit dem Vorteil: Ist schneller, da der Upload vom Storage Account bei Hotzner schneller ist, als der von mir daheim.

Mal ein Rsync-Beispiel, gedacht für Debian:

#!/bin/bash
# ==============================================================================
# UNIFIED LINUX MIGRATION SCRIPT (Executed from Source Server)
# ==============================================================================
set -e
# --- KONFIGURATION ---
TARGET_IP="ZIEL_SERVER_IP"
TARGET_USER="root"
NEW_HOSTNAME="node-new-migrated"
# Netzwerk-Konfiguration für das Zielsystem (/etc/network/interfaces)
TARGET_NETMASK="255.255.255.0"
TARGET_GATEWAY="192.168.1.1"
TARGET_DNS="1.1.1.1 8.8.8.8"
# SSH-Key Konfiguration
SSH_KEY_PATH="$HOME/.ssh/id_migration_tmp"
echo "=== SCHRITT 1: SSH-Schlüsselpaare einrichten ==="
if [ ! -f "$SSH_KEY_PATH" ]; then
echo "Generiere temporären SSH-Schlüssel..."
mkdir -p "$HOME/.ssh"
chmod 700 "$HOME/.ssh"
ssh-keygen -t ed25519 -N "" -f "$SSH_KEY_PATH"
fi
echo "Kopiere öffentlichen Schlüssel auf den Zielserver..."
echo "--> HINWEIS: Bitte geben Sie jetzt das Passwort für $TARGET_USER@$TARGET_IP ein."
ssh-copy-id -i "${SSH_KEY_PATH}.pub" "${TARGET_USER}@${TARGET_IP}"
# Definiere SSH-Alias mit dem spezifischen Key für alle folgenden Remote-Befehle
ssh_target() {
ssh -i "$SSH_KEY_PATH" -o StrictHostKeyChecking=accept-new "${TARGET_USER}@${TARGET_IP}" "$@"
}
echo "=== SCHRITT 2: Erster Vorab-Sync (Live-System im Hintergrund) ==="
rsync -aHAXxv --numeric-ids --progress -e "ssh -i $SSH_KEY_PATH" \
--exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found} \
--exclude={/etc/fstab,/etc/network/interfaces,/etc/netplan/*,/etc/sysconfig/network-scripts/*} \
--exclude={/boot/efi/*,/etc/udev/rules.d/70-persistent-net.rules} \
/ ${TARGET_USER}@${TARGET_IP}:/
echo "=== SCHRITT 3: Ermittle und stoppe alle lokalen Dienste (außer SSH) ==="
SERVICES_TO_STOP=$(systemctl list-units --type=service --state=active --no-legend | awk '{print $1}' | grep -E -v '^(ssh|sshd|systemd-|dbus|networking|resolvconf|getty|rc-local|kmod)')
echo "Folgende Dienste werden jetzt gestoppt:"
echo "$SERVICES_TO_STOP"
echo "----------------------------------------"
for svc in $SERVICES_TO_STOP; do
echo "Stoppe $svc..."
systemctl stop "$svc" echo "Warnung: $svc konnte nicht gestoppt werden."
done
echo "=== SCHRITT 4: Finaler Delta-Sync (Downtime-Phase) ==="
rsync -aHAXxv --numeric-ids --delete --progress -e "ssh -i $SSH_KEY_PATH" \
--exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found} \
--exclude={/etc/fstab,/etc/network/interfaces,/etc/netplan/*,/etc/sysconfig/network-scripts/*} \
--exclude={/boot/efi/*,/etc/udev/rules.d/70-persistent-net.rules} \
/ ${TARGET_USER}@${TARGET_IP}:/
echo "=== SCHRITT 5: Remote-Konfiguration auf dem Zielserver ausführen ==="
# Wir senden einen kombinierten Bash-Block direkt via SSH an den Zielserver
ssh_target bash << EOF
set -e
echo "[Ziel] Passe Hostname an..."
hostnamectl set-hostname "$NEW_HOSTNAME"
sed -i "s/127.0.1.1.*/127.0.1.1 $NEW_HOSTNAME/g" /etc/hosts
echo "[Ziel] Konfiguriere Netzwerkkarte..."
PRIMARY_IFACE=\$(ip -4 route show default | awk '{print \$5}' | head -n1)
if [ -z "\$PRIMARY_IFACE" ]; then
PRIMARY_IFACE="eth0"
fi
cat << NETED > /etc/network/interfaces
auto lo
iface lo inet loopback
auto \$PRIMARY_IFACE
iface \$PRIMARY_IFACE inet static
address $TARGET_IP
netmask $TARGET_NETMASK
gateway $TARGET_GATEWAY
dns-nameservers $TARGET_DNS
NETED
rm -f /etc/udev/rules.d/70-persistent-net.rules
echo "[Ziel] Passe Speicher-UUIDs in /etc/fstab an..."
cp /etc/fstab /etc/fstab.bak
TARGET_ROOT_DEV=\$(mount | grep ' / ' | awk '{print \$1}')
TARGET_ROOT_UUID=\$(blkid -o value -s UUID "\$TARGET_ROOT_DEV")
if [ -n "\$TARGET_ROOT_UUID" ]; then
sed -i -E "s|UUID=[a-f0-9-]+\s+/\s+|UUID=\${TARGET_ROOT_UUID} / |g" /etc/fstab
echo "[Ziel] Root-UUID erfolgreich aktualisiert."
else
echo "[Ziel] FEHLER: Neue Root-UUID konnte nicht ermittelt werden."
fi
echo "[Ziel] Baue Initramfs und Bootloader (GRUB) neu..."
if command -v update-initramfs >/dev/null 2>&1; then
update-initramfs -u -k all
update-grub
elif command -v dracut >/dev/null 2>&1; then
dracut --regenerate-all --force
grub2-mkconfig -o /boot/grub2/grub.cfg
fi
echo "[Ziel] Aktiviere übernommene Dienste für den nächsten Systemstart..."
for svc in $SERVICES_TO_STOP; do
if [ -n "\$svc" ]; then
systemctl enable "\$svc" echo "[Ziel] Konnte \$svc nicht aktivieren."
fi
done
EOF
echo "=============================================================================="
echo " MIGRATION ERFOLGREICH BEENDET! "
echo " Das Zielsystem wurde konfiguriert und alle Daten abgeglichen."
echo "=============================================================================="

Voraussetzung sind 2 identische Debian-Versionen, Devicenamen (nicht UUID) identisch. Wenn das erfolgreich gelaufen ist würde ich mich auf dem Zielsystem umsehen und mal einen Reboot versuchen… Da ist noch Nacharbeit bei den Diensten (andere IP etc.) und wahrscheinlich auch im DNS.

Pack das am besten einmal alles sauber in einen Code Block.

- Übersichtlicher

- Woltlab ersetzt nichts zu Emojis

Zitat von fvbor

Pack das am besten einmal alles sauber in einen Code Block.

- Übersichtlicher

- Woltlab ersetzt nichts zu Emojis

Jupp, bin nicht Woltlab-erfahren, weiß aber jetzt wie es geht

Ich will hier niemanden davon abhalten, Server zu bestellen und Netcup Geld zu geben, aber wieso nimmt man für das Ping Pong Spiel mit der Installation nicht einfach eine eigene VM?

Zitat von NaN

..., aber wieso nimmt man für das Ping Pong Spiel mit der Installation nicht einfach eine eigene VM?

Eventuell nicht, weil der Upload des eigenen Internet-Providers zu gering ist?

Zitat von zeropage

Nun ist mir eine weitere Variante in den Sinn gekommen: Für einen Monat einen zweiten Server mieten, dort alles installieren, davon ein Image-Backup erstellen und dann das Backup auf den alten (!) Server einspielen. Und schließlich (teuren) Zweitserver wieder kündigen.

Ich würde es allerdings so machen, dass ich den alten Server auf den Neuen duplizieren würde und dann mein neues System gleich auf dem alten Server aufsetzen...

Geht auch einfach mit nem Bootimage von Clonezilla...

Zitat von zeropage

Wenn ich es richtig verstanden habe, müsste der rsync oder dd von einem dritten System mit Zugriff auf die offline Disk(s) erfolgen?

Idealerweise, ja. Mit dd ginge es nur mit einem Snapshot online. Wenn bei der Installation kein entsprechender Abstraktionslayer verwendet wurde, heißt das, es geht nur offline. Um die Downtime zu verringern könntest du mit rsync den Hauptteil der Arbeit auch online machen und dann offline nur nacharbeiten lassen, was sich geändert hat.

Ein drittes System brauchst du dazu nicht. Einen Server bei Netcup kannst du im Rettungssystem oder mit einem anderen Live-Linux deiner Wahl von DVD booten, so dass der Speicher nicht von einem Betriebssystem in Benutzung ist, während du mit rsync drüberbügelst.

Zitat von ASS

Ich würde es allerdings so machen, dass ich den alten Server auf den Neuen duplizieren würde und dann mein neues System gleich auf dem alten Server aufsetzen..

Wahrscheinlich ist das sogar die beste Variante.(Manchmal ist es so einfach, dass man es übersieht. )

Zitat von zeropage

Hallo allerseits,

ich möchte meinen Root Server G9.5 initialisieren und neu aufsetzen. Um einen Downtime zu vermeiden, habe ich dazu in der Vergangenheit einfach zwei Server für einen Monat parallel betrieben und den alten gekündigt. Wegen des nun aber damit verbundenen Preisanstiegs beim G12.5 habe ich Zweifel an dieser Vorgehensweise. Statt Preisanstieg müsste ich von RS auf VPS umzusteigen.

Nun ist mir eine weitere Variante in den Sinn gekommen: Für einen Monat einen zweiten Server mieten, dort alles installieren, davon ein Image-Backup erstellen und dann das Backup auf den alten (!) Server einspielen. Und schließlich (teuren) Zweitserver wieder kündigen.

Hat das jemand schon mal so gemacht? Gibt es irgendwelche Pitfalls, an die ich nicht denke? Oder gar eine weitere, bessere Vorgehensweise?

Danke, Titus

Verzeih mir die vlt dumme Frage aber wenn du den Server sowieso neu machst, dann wirst du doch Zwangsweise eine Downtime haben oder nicht? Warum also nicht einfach eine kurze Downtime ankündigen das der Server mal ne Stunde offline ist? Vorher einfach ein Script schreiben das installiert was du installieren willst und das letzte Backup wieder einspielen und fertig? Da sollte man doch in wenigen Minuten durch kommen.. Bevor du diesen Zauber mit Rsync machst und am Ende eine viel längere Downtime hast..

Zitat von hra42

Vorher einfach ein Script schreiben

Es gibt Leute, die beim Neuinstallieren nicht einfach ein Update durchführen, sondern auch verschiedene neue Sachen, Programme, Konfigurationen ausprobieren wollen.

Zitat von hra42

Da sollte man doch in wenigen Minuten durch kommen..

Nein. Das ist ganz sicher nicht in wenigen Minuten erledigt.
(Bei einigen meiner Server dauert sowas immer etliche Stunden, meist über mehrere Tage verteilt)

In der Regel setzt man einen Server ja nicht ohne Grund neu auf. Meistens ist es eine neue Version des Betriebssystems auf das man umziehen will. Das verhält sich nicht exakt so wie das Alte.
Hier muss man, wenn man es sauber machen will, stückweise installieren, überprüfen und evtl. die Konfiguration anpassen.
Insbesondere bei einem Server der vielfältig abgesichert ist und auf dem viele unterschiedliche Anwendungen laufen, kann das schon mal länger dauern. Auch die aus den Backups wiederhergestellten Anwendungen müssen ja dann sorgfältig überprüft werden. ob auch alles mit der neuen OS-Version zusammenspielt. Insbesondere bei php kann das zu unlustigen Überraschungen führen.
Einen produktiven Server auf andere Art neu aufzusetzen wäre in meinen Augen nicht empfehlenswert.

Wenn es allerdings nur darum geht, eine weitere, weitgehend identische Instanz eines Servers zu erstellen, dann kann man das natürlich tatsächlich u.U. schneller über Skripte machen.