← Zurück zum Blog

Incus-Instanzen kopieren – minimale Downtime mit Snapshots

Incus-Instanzen kopieren – minimale Downtime mit Snapshots

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 Differenz
  • incus 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 create nutzt 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?).