Eine Docker-VM pro App oder ein LXC pro App: Was bietet eine bessere Kontrolle über Backups und den Schadensradius?

Wählen Sie eine Docker-VM, wenn die Anwendungen eine gemeinsame Betriebsumgebung, einen Reverse Proxy, einen Monitoring-Stack und einen Backup-Zeitplan nutzen und es akzeptabel ist, die gesamte Anwendungsplattform gemeinsam wiederherzustellen. Wählen Sie ein LXC pro App, wenn Dienste unterschiedliche Risiko-, Update-, Speicher- oder Wiederherstellungsanforderungen haben und ein fehlerhaftes Paket, ein fehlerhafter Mount oder eine fehlerhafte Anwendung den Rest des Stacks nicht unterbrechen sollte. Das bessere Design ist die kleinste Wiederherstellungseinheit, die Sie dokumentieren können, ohne versteckte Abhängigkeiten zu vervielfachen.

Definieren Sie die Wiederherstellungseinheit, bevor Sie Container vergleichen

Die erste Entscheidung lautet nicht, ob Docker oder LXC weniger Ressourcen benötigt. Entscheidend ist, was nach einem fehlgeschlagenen Update, einer beschädigten Datenbank, einem fehlerhaften Mount oder dem Austausch des Hosts gemeinsam wiederhergestellt werden muss. Eine einzelne Docker-VM bildet eine große Wiederherstellungseinheit für Betriebssystem und Container-Engine. Ein LXC pro App schafft mehrere kleinere Einheiten, jeweils mit eigenem Dateisystem, eigener Netzwerkidentität, eigenen Limits und eigenem Backup-Objekt.

Der ZimaSpace-Leitfaden zu Speicherebenen von Bare Metal, Docker und Proxmox erklärt, warum jede zusätzliche Ebene verändert, wo persistente Daten gespeichert werden. Dieser Vergleich beginnt, nachdem Proxmox bereits ausgewählt wurde, und fragt, wie groß die Wiederherstellungsgrenze jeder Anwendung sein sollte.

Wenn die Anwendungen nicht unabhängig voneinander starten können, weil sie eine Datenbank, ein Compose-Netzwerk, einen Identitätsanbieter oder eine Reverse-Proxy-Konfiguration gemeinsam nutzen, erzeugt die Erstellung separater LXCs möglicherweise mehrere Backup-Dateien, aber keine echte Isolation. Erfassen Sie die Abhängigkeiten, bevor Sie Container zählen.

Eine einzelne Docker-VM vereinfacht die Plattform-Sicherung

Eine einzelne VM kann den Linux-Gast, die Docker Engine, Compose-Dateien, Geheimnisse, die Proxy-Konfiguration, Container-Images und persistente Volumes enthalten. Proxmox kann die VM als ein Objekt sichern, was den Austausch des Hosts und ein umfassendes Zurücksetzen unkompliziert macht, wenn der gesamte Stack auf denselben Zeitpunkt zurückgesetzt werden soll.

Ein aktueller Leitfaden zur Wiederherstellung von Proxmox-VMs und LXC-Containern weist darauf hin, dass LXC-Wiederherstellungen oft weniger Aufwand erfordern, weil sie ein Container-Dateisystem statt einer vollständigen virtuellen Festplatte archivieren. Der umgekehrte Vorteil einer VM ist ihre Vollständigkeit: Eine einzige Wiederherstellung kann das Gastbetriebssystem und die Docker-Umgebung gemeinsam zurückbringen.

Diese Einfachheit ist besonders vorteilhaft, wenn Anwendungen bewusst eine gemeinsame Plattform bilden. Ein Medien-Stack kann sich einen Reverse-Proxy, Authentifizierung, Download-Tools, Monitoring und Speichereinbindungen teilen. Nur einen Teil wiederherzustellen, kann zu Versions- oder Zugangsdatenkonflikten führen, sodass ein gemeinsames VM-Backup möglicherweise besser der tatsächlichen Abhängigkeitsgrenze entspricht.

Separate LXCs bieten kleinere Einheiten für Fehler und Wiederherstellung

Ein LXC pro App sorgt dafür, dass ein fehlerhaftes Paket, ein vollständig belegtes Root-Dateisystem, eine beschädigte Konfiguration oder ein fehlgeschlagenes Update auf einen Gast beschränkt bleibt. Der Betreiber kann diesen Container wiederherstellen, ohne unabhängige Services zurückzusetzen, die sich nach demselben Sicherungspunkt erfolgreich geändert haben.

Das praktische Argument für kleinere Auswirkungsbereiche von Services in Proxmox ist nicht, dass jede Anwendung automatisch einen Container verdient. Es geht darum, dass Isolation wertvoll ist, wenn Services unterschiedliche Anforderungen an Vertrauen, Wartung oder Verfügbarkeit haben.

Der Vorteil verschwindet, wenn alle LXCs dasselbe beschreibbare Anwendungsverzeichnis einbinden, von einer einzigen ungeschützten Datenbank abhängen oder denselben Proxy- und Identitätsdienst benötigen. Ein separates Root-Dateisystem kann keinen Ausfall eindämmen, der sich über gemeinsam genutzte Zugangsdaten, Speicher oder destruktive Automatisierung ausbreitet.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Eine feinere Backup-Granularität kann mehr Wiederherstellungsarbeit verursachen

Kleinere Backups ermöglichen es dem Betreiber, wichtige Dienste separat aufzubewahren, wiederherzustellen und zu testen. Ein Home-Assistant-LXC kann häufige Backups erhalten, während ein ersetzbares Dashboard eine kürzere Aufbewahrungsrichtlinie haben kann. Der Backup-Zeitplan kann sich an Änderungsrate und -folgen orientieren, statt jede Anwendung gleich zu behandeln.

Der Preis dafür ist der Orchestrierungsaufwand. Die Wiederherstellung von fünf LXCs kann die richtige Startreihenfolge, feste Adressen, DNS-Einträge, Speichereinbindungen, Zertifikate und Dienstzugangsdaten erfordern. Ein Backup, das jeden Gast separat erfasst, bewahrt den Abhängigkeitsgraphen zwischen ihnen nicht automatisch.

Der Proxmox-Backup-Server-Workflow von ZimaSpace kann sowohl VMs als auch Container schützen. Die Paketentscheidung liegt weiterhin bei Ihnen: Legen Sie fest, welche Dienste einen gemeinsamen Wiederherstellungspunkt benötigen und welche unabhängig wiederherstellbar sein sollen.

Updates zeigen den tatsächlichen Schadensradius

In einer Docker-VM können ein Betriebssystem-Update, eine Änderung am Docker-Daemon, eine Änderung an iptables oder nftables, ein voller Datenträger oder ein Dateisystemproblem jeden Container stoppen. Docker hält die Anwendungspaketierung getrennt, aber Gastkernel, Daemon, Speicher-Treiber und Netzwerk-Stack werden weiterhin gemeinsam genutzt.

Separate LXCs verlagern viele dieser Änderungen in kleinere Gäste. Eine Anwendung kann eine andere Paketversion oder einen anderen Neustartplan verwenden, ohne die Umgebung aller anderen Dienste zu verändern. Das ist für öffentlich zugängliche Apps, experimentelle Software oder Dienste mit aggressiven Updatezyklen nützlich.

Allerdings nutzt jeder LXC weiterhin den Kernel des Proxmox-Hosts gemeinsam. Ein Ausfall des Host-Kernels, des Speichers, der Netzwerkbrücke oder von Proxmox bleibt ein gemeinsames Ereignis. Ein LXC pro App verringert den Schadensradius auf Gastebene, schafft aber keine Unabhängigkeit vom Host.

Gemeinsam genutzte Datenbanken und Proxys können eine bessere Gruppierung vorgeben als „eine App“

Anwendungen bestehen häufig aus mehreren Komponenten: Webdienst, Datenbank, Cache, Worker, Scheduler und Proxy-Route. Wenn jede Komponente in ein anderes LXC aufgeteilt wird, kann die normale Wiederherstellung schwieriger werden, da sich der konsistente Zustand der Anwendung über mehrere Gäste erstreckt.

Eine bessere Einheit kann ein LXC pro Anwendungs-Stack sein, mit Docker Compose innerhalb dieses LXCs für eng gekoppelte Komponenten. Eine weitere Option ist eine Docker-VM für risikoarme, zusammengehörige Dienste sowie separate LXCs für Datenbanken, öffentliche Anwendungen oder hardwareabhängige Workloads.

Die Proxmox-Community-Diskussion darüber, wie viele Anwendungen zu jedem Gast gehören, spiegelt die praktische Realität wider: Die Trennung sollte sich nach Abhängigkeiten, Sicherheit und Wiederherstellungsanforderungen richten, nicht nach einer universell gültigen Anzahl von Anwendungen.

Persistenter Speicher entscheidet darüber, ob das Backup vollständig ist

Ein VM-Backup erfasst möglicherweise virtuelle Laufwerke, schließt jedoch NAS-Bind-Mounts, externe NFS-Freigaben, durchgereichten Speicher oder an anderer Stelle gespeicherte Anwendungs-Backups aus. Ein LXC-Backup erfasst möglicherweise sein Root-Dateisystem, während per Bind-Mount eingebundene Datasets außerhalb des Archivs verbleiben. Keine der beiden Architekturen garantiert eine vollständige Wiederherstellung, nur weil der Proxmox-Job einen Erfolg meldet.

Inventarisieren Sie Compose-Dateien, Secrets, Datenbanken, hochgeladene Inhalte, Zertifikate, externe Mounts und Backup-Ziele. Kennzeichnen Sie, ob sich jeder Pfad innerhalb des VM- oder LXC-Backups befindet, durch einen separaten Snapshot geschützt ist oder aus der Konfiguration neu erstellt wird.

Dies ist die Abbruchgrenze: Wenn der persistente Anwendungsstatus auf einem einzigen gemeinsam genutzten, ungeschützten Pfad liegt, verbessert eine Änderung der Anzahl der Gäste die Wiederherstellung nicht. Korrigieren Sie die Datengrenze, bevor Sie die Granularität der Backups optimieren.

Führen Sie eine Ausfallübung für beide Designs durch

1. Listen Sie jede Anwendung, gemeinsame Abhängigkeit, jeden persistenten Pfad und jeden externen Mount auf.
2. Legen Sie für jeden Dienst den maximal akzeptablen Ausfall und Datenverlust fest.
3. Stellen Sie die vollständige Docker-VM unter einer neuen Gast-ID wieder her und überprüfen Sie den gesamten Stack.
4. Stellen Sie ein repräsentatives LXC wieder her, ohne unabhängige Anwendungen zu verändern.
5. Testen Sie Startreihenfolge, DNS, Zertifikate, Datenbankzugriff und die Verfügbarkeit von Mounts.
6. Unterbrechen Sie absichtlich die Aktualisierung eines Gasts und beobachten Sie, welche Dienste ausfallen.
7. Wiederholen Sie die Wiederherstellung ausschließlich anhand der schriftlichen Dokumentation.

Messen Sie neben der Wiederherstellungszeit auch die Anzahl der Arbeitsschritte für die Administration. Ein kleines LXC-Archiv ist nicht automatisch betrieblich einfacher, wenn seine Wiederherstellung den Neuaufbau von zehn undokumentierten Abhängigkeiten erfordert. Eine größere VM-Sicherung ist nicht sicherer, wenn ein Rollback gültige Änderungen aus jeder Anwendung entfernt.

Welches Gast-Layout passt zum App-Stack?

Wählen Sie eine Docker-VM, wenn

Wählen Sie eine VM, wenn Anwendungen Infrastruktur gemeinsam nutzen, gemeinsam gewartet werden und einen gemeinsamen Sicherungs- und Rollback-Punkt akzeptieren können. Halten Sie persistente Datenpfade explizit fest, ergänzen Sie anwendungsorientierte Datenbanksicherungen und überwachen Sie die gemeinsame VM als kritische Plattform.

Wählen Sie einen LXC pro App oder App-Stack, wenn

Wählen Sie separate LXCs, wenn Dienste unterschiedliche Anforderungen an Risiko, Vertrauen, Hardwarezugriff, Aktualisierungen oder Aufbewahrung haben. Gruppieren Sie eng gekoppelte Komponenten und automatisieren Sie die gemeinsame Basiskonfiguration, damit Isolation nicht zu wiederholter manueller Arbeit führt.

Verwenden Sie ein hybrides Layout, wenn

Platzieren Sie risikoarme, zusammengehörige Docker-Dienste in einer VM und isolieren Sie öffentliche Apps, Datenbanken, Home Assistant oder hardwareabhängige Workloads in dedizierten LXCs oder VMs. Das bietet in der Regel sinnvollere Grenzen, als auf jeden Dienst dieselbe Architektur anzuwenden.

Häufig gestellte Fragen

Entfällt durch einen LXC pro App die Notwendigkeit von Docker?

Nein. Ein LXC kann ein natives Paket ausführen oder einen kleinen Docker-Compose-Stack hosten. LXC definiert die Grenze des Proxmox-Gasts; Docker definiert die Paketierung der Anwendungen innerhalb dieser Grenze. Beide lösen unterschiedliche Probleme bei Isolation und Bereitstellung.

Ist eine große VM einfacher zu sichern?

Die Planung und Wiederherstellung als ein Objekt ist einfacher, aber das Archiv ist größer und ein Rollback betrifft jede Anwendung. Separate Anwendungssicherungen können für Datenbanken und extern eingebundene Daten weiterhin erforderlich sein.

Können LXCs zwischen Proxmox-Knoten migriert werden?

Ja, aber Gerätez Zuordnungen, lokale Bind-Mounts, Host-Treiber, Speicherpfade und Netzwerkanforderungen müssen möglicherweise neu eingerichtet werden. Das Root-Dateisystem lässt sich leichter verschieben als der vollständige Hardware- und Speichervertrag.

Abschließendes Urteil

Verwenden Sie eine Docker-VM, wenn die Anwendungen tatsächlich eine gemeinsame Plattform bilden und gemeinsam gesichert, gepatcht und wiederhergestellt werden sollen. Verwenden Sie separate LXCs, wenn Dienste unabhängige Wiederherstellungspunkte und kleinere Fehlerdomänen auf Gastebene benötigen. Das sinnvollste Layout gruppiert Dienste nach gemeinsamem Zustand und gemeinsamer Wiederherstellungsverantwortung, statt blind einen Gast pro Symbol zu wählen.