Wer Incus-Instanzen zwischen Servern verschiebt, kennt das Problem: Ein incus copy einer 100-GB-Instanz dauert lange. Und während des Kopierens muss die Quell-Instanz stillstehen – jede Minute Downtime zählt.
Es gibt einen Trick: --stateless und --refresh in Kombination mit Snapshots. Damit lässt sich die Downtime von Stunden auf Minuten reduzieren.
Das Problem
Ein normales incus copy funktioniert so:
incus copy quelle:mein-container mein-container
Das kopiert den gesamten Speicher – währenddessen muss die Quelle stillstehen, weil sich die Daten sonst ändern. Bei einer 100-GB- Instanz sind das locker mal je nach Netzwerkbandbreite 15–30 Minuten Downtime.
Die Lösung: Zweistufiges Kopieren
Mein Skript copy_instance.sh macht es anders:
#!/bin/bash
set -e
if [ "x$2" == "x" ]; then
echo "usage: $0 <instance> <src server>"
exit 1
fi
instance=$1
src=$2
# 1. Snapshot while running (initial)
incus snapshot create $src:$instance
# 2. Copy stateless (fast, instance keeps running)
incus copy $src:$instance $instance --stateless
# 3. Stop the source
incus stop $src:$instance
# 4. Final snapshot (while stopped)
incus snapshot create $src:$instance
# 5. Refresh copy (only the diff)
incus copy $src:$instance $instance --refresh
# 6. Start on destination
incus start $instance
Was passiert, Schritt für Schritt
1. Erster Snapshot (Quellinstanz läuft weiter)
incus snapshot create $src:$instance
Der Container läuft weiter. Der Snapshot friert den aktuellen Zustand ein – ohne den laufenden Betrieb zu unterbrechen.
2. Stateless Copy
incus copy $src:$instance $instance --stateless
--stateless kopiert den Snapshot ohne den laufenden Zustand (RAM, offene Dateien, CPU-Register). Das ist deutlich schneller, weil nur die Datenblöcke kopiert werden. Die Quell-Instanz läuft weiter – keine Downtime.
3. Quelle stoppen
incus stop $src:$instance
Jetzt kommt die einzige echte Downtime – aber sie ist kurz, weil der Großteil der Daten schon kopiert ist.
4. Zweiter Snapshot (Quellinstanz gestoppt)
incus snapshot create $src:$instance
Der zweite Snapshot nimmt den finalen Zustand auf – alle Änderungen seit dem ersten Snapshot.
5. Refresh Copy
incus copy $src:$instance $instance --refresh
Das ist der Trick: --refresh kopiert nur die Differenz zwischen dem ersten und dem zweiten Snapshot. Das sind typischerweise nur wenige Megabyte bis wenige Gigabyte – abhängig davon, wie viel sich während der Kopierzeit geändert hat.
6. Start auf dem Ziel
incus start $instance
Die Instanz läuft auf dem neuen Server. Durch mein Netbird-Mesh ist der Service sofort auf dem neuen Server ansprechbar.
Die Vorteile
| Methode | Downtime | Geschwindigkeit |
|---|---|---|
Normales incus copy |
Gesamte Kopierdauer | Langsam (100% der Daten) |
--stateless + --refresh |
Nur Stop/Start | Schnell (95% vorab, Rest = Diff) |
Die Downtime setzt sich zusammen aus:
incus stop– wenige Sekunden- Zweiter Snapshot – abhängig von der Änderungsrate
--refresh– nur die Differenzincus start– wenige Sekunden
Bei einer 100-GB-Instanz mit geringer Änderungsrate sind das weniger als 2 Minuten statt 30.
Wann funktioniert das?
Die Methode braucht ein Dateisystem mit Snapshots:
- ZFS –
incus snapshot createnutzt ZFS-Snapshots (instant) - Btrfs – ebenfalls unterstützt
- LVM – Snapshots möglich, aber langsamer
Ohne Snapshots (reiner Directory-Backend) funktioniert --refresh nicht – dann bleibt nur das normale Kopieren.
Fazit
incus copy ist bequem, aber bei großen Instanzen langsam. Mit --stateless + --refresh bekommt man die Downtime auf ein Minimum reduziert – vorausgesetzt, das Backend unterstützt Snapshots.
Das Skript ist absichtlich kurz gehalten. Wer es robuster braucht, kann set -x einkommentieren und Prüfungen einbauen (Snapshot vorhanden? Ziel existiert schon?).
