2026 Proxmox VE 9.2: Wie aktualisiert man OCI-Image-Container?

Der Container läuft nach dem Austausch des OCI-Images nicht wie erwartet, oder nach dem Neuerstellen fehlen Anwendungsdaten.

Schnellste Lösung: Behandeln Sie ein neues Image nicht als Update des laufenden Containers. Prüfen Sie zuerst die dokumentierten Möglichkeiten Ihrer installierten Proxmox-Version, sichern Sie die persistenten Daten und testen Sie den kontrollierten Ersatz, bevor Sie den bisherigen Container abschalten.

Diese Anleitung ist für Administratoren gedacht, die OCI-Image-Container unter Proxmox VE testen oder einen Aktualisierungsfehler beheben.
Auch MSP, die mehrere Anwendungsinstanzen reproduzierbar pflegen müssen, finden hier einen Ablauf für Sicherung, Austausch und Abnahme.
Wenn ein Dienst dauerhaft laufen soll, ist außerdem die Abgrenzung zu einer Container-Laufzeit in einer VM relevant.

Versionsstand und Funktionsgrenze

Proxmox VE 9.1 führte laut offizieller Veröffentlichung die Möglichkeit ein, LXC-Container aus OCI-Images zu erstellen. Proxmox VE 9.2 wurde am 21.05.2026 veröffentlicht; die konkrete Bedienung und die unterstützten Abläufe sollten anhand der für diese Version geltenden Dokumentation geprüft werden. Die Veröffentlichungstermine und Funktionsangaben sind in den offiziellen Hinweisen zu Proxmox VE 9.1 und Proxmox VE 9.2 dokumentiert. Stand der Prüfung: 26.10.2026.

Das Erstellen eines LXC-Containers aus einem OCI-Image ist nicht dasselbe wie ein vollständiger Docker-Betrieb. Ein Image ist zunächst eine Vorlage für einen Container. Daraus folgt nicht, dass Proxmox ein bereits laufendes Exemplar automatisch aktualisiert, Anwendungsdaten aus dem alten Exemplar übernimmt oder den vollständigen Workflow einer Docker-Umgebung abbildet.

Die Proxmox-Containerverwaltung ist maßgeblich für die konkreten Containeraktionen. Prüfen Sie dort, ob die jeweilige Funktion für die installierte Version beschrieben ist. Eine aktuelle Dokumentationsseite oder ein Eintrag in einer neueren Version darf nicht ohne Prüfung als Zusage für einen älteren Host ausgelegt werden. Verwenden Sie weder einen im Forum genannten Befehl noch einen vermuteten GUI-Pfad, wenn er nicht durch die passende Dokumentation gedeckt ist.

Auch die Image-Seite verdient eine Prüfung: Ein OCI-Image umfasst ein Manifest, das unter anderem auf die zugehörigen Image-Konfigurationen und Layer verweist. Das erklärt, warum ein neuer Tag oder ein geändertes Manifest allein noch nichts am Dateisystem eines bereits gestarteten Containers ändert. Die OCI-Spezifikation zum Image-Manifest beschreibt diese Image-Struktur; sie dokumentiert jedoch nicht, welche Update-Aktion Proxmox für einen bestehenden Container anbietet.

Image-Wechsel und laufender Container

Ein häufiger Irrtum besteht darin, das Laden eines neuen Images mit dem Aktualisieren einer laufenden Instanz gleichzusetzen. Das sind verschiedene Vorgänge: Ein Image kann verfügbar gemacht oder als Grundlage einer neuen Instanz verwendet werden, ohne dass sich der bereits gestartete Container ändert. Ebenso wenig belegt das Vorhandensein eines neueren Tags, dass Konfiguration, Laufzeitstatus und Daten automatisch in eine neue Instanz übernommen werden.

Für den Betrieb sollten daher vier Zustände getrennt protokolliert werden:

• Image beschafft: Das gewünschte Image ist verfügbar und seine Herkunft sowie der verwendete Tag sind festgehalten.
• Container erstellt: Eine Instanz wurde aus der vorgesehenen Grundlage angelegt; ihre ID und Konfiguration sind bekannt.
• Anwendung geprüft: Der Dienst startet, ist erreichbar und kann auf die benötigten Daten zugreifen.
• Produktiv umgeschaltet: Der Zugriff führt auf die geprüfte Instanz, und der Rückweg ist weiterhin ausführbar.

Diese Trennung ist insbesondere bei einem Tag relevant, der sich ändern kann. Für eine nachvollziehbare Bereitstellung sollte die konkrete Image-Referenz festgehalten werden. Ein beweglicher Tag kann bei einem späteren Abruf auf einen anderen Image-Inhalt verweisen; deshalb darf er nicht allein als ausreichende Versionsdokumentation gelten.

Diskussionen im Proxmox-Forum zu OCI-Images in LXC und in einer Community-Diskussion zu OCI-Container-Updates zeigen, dass Anwender nach Updatepfad, Mounts und Funktionsgrenzen fragen. Das sind Nutzerberichte und Hinweise auf offene praktische Fragen, aber keine offizielle Funktionszusage. Vor einem Produktiveinsatz ist die für den eigenen PVE-Stand dokumentierte Vorgehensweise entscheidend.

Persistente Daten vor dem Ersatz

Vor dem Austausch muss feststehen, welche Inhalte mit dem Container verschwinden dürfen und welche unabhängig vom Image erhalten bleiben müssen. Dazu gehören oft mehr als die offensichtlichen Datenbankdateien: Anwendungskonfiguration, hochgeladene Dateien, Schlüssel, Zertifikate, selbst angelegte Skripte und Einstellungen für Netzwerk oder Startverhalten können ebenfalls betroffen sein.

Erfassen Sie die tatsächlichen Pfade, an denen die Anwendung schreibt. Ein Verzeichnis, das innerhalb des Container-Dateisystems liegt, ist nicht automatisch ein externer persistenter Speicher. Umgekehrt ist ein eingebundener Speicher nicht automatisch korrekt gesichert oder in einer neuen Instanz unter demselben Pfad verfügbar. Die Dokumentation zu Proxmox-Container-Backups und Wiederherstellung hilft, die vorgesehenen Sicherungs- und Wiederherstellungswege einzuordnen. Sie ersetzt aber keine Prüfung, ob ein konkreter Anwendungszustand in einer Testwiederherstellung tatsächlich funktioniert.

Sichern Sie mindestens die Daten, die außerhalb des Images weiterbestehen müssen, und dokumentieren Sie, wie sie der neuen Instanz zugeordnet werden. Bei Datenbanken ist zusätzlich zu klären, ob eine konsistente Sicherung erstellt wird; ein bloßes Kopieren geöffneter Dateien kann unbrauchbar sein. Prüfen Sie außerdem, ob der Dienst nach dem Austausch dieselben Berechtigungen, Umgebungsvariablen und Netzwerkparameter benötigt. Diese Angaben sind Teil des reproduzierbaren Betriebs, auch wenn sie nicht im Image selbst gespeichert sind.

Löschen Sie die alte Instanz nicht unmittelbar nach dem ersten erfolgreichen Start des Ersatzes. Halten Sie sie oder einen nachweislich wiederherstellbaren Sicherungsstand so lange verfügbar, bis die neue Anwendung unter realistischen Bedingungen geprüft wurde. Welche Rückfallmöglichkeit tatsächlich besteht, hängt von Storage, Sicherungsart und PVE-Version ab; eine allgemeine Wiederherstellungsgarantie lässt sich daraus nicht ableiten.

Kontrollierter Austausch in der Praxis

Der folgende Ablauf trennt Vorbereitung, Erprobung und Umschaltung. Er ist bewusst kein behaupteter universeller Updatebefehl: Die konkrete Erstellung und Verwaltung muss zur installierten Version und zur dafür dokumentierten Proxmox-Funktion passen.

1. Bestand aufnehmen. Notieren Sie PVE-Version, Container-ID, Image-Referenz, Mountpoints, Netzwerkeinstellungen, Startparameter und die für die Anwendung benötigten Variablen. Sichern Sie relevante Konfigurationen außerhalb der Instanz.
2. Wiederherstellung vorbereiten. Ermitteln Sie, welche Daten gesichert werden müssen, wo die Sicherung liegt und wie sie zurückgespielt wird. Prüfen Sie vor einer produktiven Änderung, dass der vorgesehene Sicherungsweg für die verwendeten Mounts geeignet ist.
3. Neues Image verifizieren. Prüfen Sie die Image-Referenz und dokumentieren Sie, welche Version beziehungsweise welcher Inhalt getestet wird. Verwechseln Sie einen erfolgreich beschafften Image-Inhalt nicht mit einem abgeschlossenen Update.
4. Testinstanz erstellen. Verwenden Sie einen nicht produktiven Container oder einen getrennten Testaufbau. Übernehmen Sie nur die erforderlichen Konfigurationen und Mounts, statt unbekannte Einstellungen blind zu kopieren.
5. Anwendung erproben. Kontrollieren Sie Startverhalten, Anwendungszugriff, Datenzugriff, Netzwerk und Protokolle. Testen Sie auch einen Neustart, damit ein nur im Arbeitsspeicher vorhandener Zustand nicht mit persistenter Speicherung verwechselt wird.
6. Umschaltung planen. Legen Sie ein Wartungsfenster fest, bestimmen Sie den Umschaltweg und halten Sie fest, wie der bisherige Dienst wieder erreichbar gemacht wird. Ist der Rückweg nicht getestet oder sind Datenänderungen während der Umschaltung ungeklärt, bleibt die alte Instanz aktiv.
7. Nachkontrolle durchführen. Prüfen Sie nach dem Umschalten erneut Zugriff, Protokolle und Daten. Dokumentieren Sie, welche Instanz produktiv ist und unter welchen Bedingungen die alte Instanz entfernt werden darf.

Vor jeder produktiven Änderung sind eine Sicherung, ein geeignetes Wartungsfenster und eine konkrete Wiederherstellungsmöglichkeit erforderlich. Besonders gefährlich ist ein Ablauf, in dem der alte Container entfernt wird, bevor Datenübernahme und Rückweg geprüft wurden. Die Proxmox-Dokumentation zu Sicherung und Wiederherstellung ist dafür eine Referenz; maßgeblich bleiben die tatsächlich verwendete Storage-Konfiguration und die dazu passende Version.

Häufige Fragen zu OCI-Images

OCI-Image in einer neuen Instanz verwenden

Ein kontrollierter Ersatz beginnt mit der Prüfung der PVE-Version und des dokumentierten Ablaufs. Danach werden Daten und Konfiguration gesichert, das neue Image festgehalten und eine separate Testinstanz erstellt. Die Umschaltung erfolgt erst, wenn Start, Anwendung und Datenzugriff funktionieren. So bleibt die Frage „Ist das Image verfügbar?“ klar von der Frage „Ist der Dienst erfolgreich aktualisiert?“ getrennt.

Daten nach dem Neuerstellen erhalten

Der Container selbst ist nicht automatisch der richtige Speicherort für dauerhaft benötigte Anwendungsdaten. Vor einem Ersatz müssen Schreibpfade, Mountpoints, Berechtigungen und Sicherungen erfasst sein. Testen Sie die Wiederherstellung in einer isolierten Instanz und kontrollieren Sie, ob die Anwendung nach einem Neustart weiterhin dieselben Daten sieht. Ohne diesen Test ist die Annahme, ein Mount oder Backup funktioniere wie erwartet, nicht belastbar.

Eignung für einen dauerhaften Produktivdienst

Ein einfacher Dienst mit wenigen, stabilen Abhängigkeiten kann nach einem erfolgreichen Test für diesen Betriebsweg geeignet sein. Häufige Image-Wechsel, mehrere eng gekoppelte Anwendungen und ausgefeilte Volume- oder Compose-Abläufe sprechen dagegen dafür, die Architektur genauer zu prüfen. Ausschlaggebend sind Updatefrequenz, Isolation, Wiederherstellbarkeit und Wartungsaufwand, nicht eine pauschale Aussage über die Leistungsfähigkeit.

OCI-Container gegenüber Docker in einer VM

Ein aus einem OCI-Image erzeugter LXC-Container und eine VM mit Docker sind unterschiedliche Betriebsmodelle. In einer VM verwaltet eine separate Container-Laufzeit die dort vorgesehenen Container-Workflows; der Proxmox-Weg erstellt einen LXC-Container auf Grundlage eines OCI-Images. Wenn Compose, mehrere Services oder ein etablierter Volume-Prozess vorausgesetzt werden, sollte der VM-Weg anhand dieser Anforderungen geprüft werden, statt Funktionsgleichheit anzunehmen.

Betriebsmodell und Abnahme vergleichen

Die passende Lösung hängt vor allem davon ab, wie oft Images wechseln, wie viele Dienste voneinander abhängen und wie zuverlässig Daten zurückgespielt werden können. Die Tabelle ist eine Entscheidungshilfe, keine Aussage über pauschale Leistungsvorteile.

Für die Abnahme sollte nicht nur die Versionsanzeige des Images zählen. Entscheidend ist, ob der Dienst nach dem Austausch tatsächlich benutzbar bleibt und ob ein Rückfall ohne ungeplanten Datenverlust möglich ist.

Bei unabhängiger Servervirtualisierung ist ein einzelner OCI-Dienst nur ein Teil der Ressourcenplanung. Weitere VMs und LXC-Anwendungen teilen sich Arbeitsspeicher, CPU-Zeit, Storage und Netzwerk. Ohne Lastmessung und Kenntnis der einzelnen Anwendungen lässt sich daraus keine belastbare feste Instanzzahl ableiten. Prüfen Sie deshalb den tatsächlichen Bedarf sowie die Entwicklung der Belegung, bevor zusätzliche Dienste auf demselben Host eingeplant werden.

Ressourcenplanung und nächster Schritt

Für eine dauerhaft betriebene Umgebung sollte die Ressourcenplanung sowohl den Proxmox-Host als auch die darin laufenden Dienste berücksichtigen. Ein zusätzlicher Container benötigt nicht nur Rechenzeit, sondern kann auch Speicherplatz für Images, Logs, temporäre Dateien und persistente Anwendungsdaten beanspruchen. Werden Sicherungen auf demselben Speicher wie die produktiven Daten abgelegt, schützt das außerdem nicht vor einem Ausfall dieses Speichers. Die Sicherungsstrategie muss deshalb zum gewünschten Wiederherstellungsziel passen.

Vor einer Beschaffung ist zu klären, wie viele Dienste tatsächlich gleichzeitig laufen, welche davon dauerhaft aktiv sein müssen und wie deren Speicherbedarf gemessen wird. Berücksichtigen Sie außerdem, ob Images regelmäßig ersetzt werden, wie viel Platz für Testinstanzen benötigt wird und ob getrennte VMs für bestimmte Workloads erforderlich sind. Ein belastbarer Plan basiert auf den beobachteten Anwendungen und einer getesteten Wiederherstellung, nicht auf einer pauschalen Zahl möglicher Container.

Wer eine solche Umgebung auf einem dedizierten AMD-Server betreiben möchte, sollte zuerst die für den konkreten Bedarf verfügbaren Systeme, Ressourcen und Storage-Optionen prüfen. Die Produktübersicht von SFP Cloud und die Preisinformationen für dedizierte Server dienen dazu, die verfügbaren Angebote mit dem eigenen Proxmox- und Datenkonzept abzugleichen. Ein dedizierter Host kann sinnvoll sein, wenn dauerhaft eigene Ressourcen für mehrere Workloads benötigt werden; er ersetzt jedoch weder einen getesteten OCI-Austausch noch eine separat geplante Datensicherung.

Häufige Fragen

1. Q
   Wie kommt ein OCI-Container unter Proxmox auf ein neues Image?

   Behandeln Sie das neue Image nicht als automatisches Update des laufenden Containers. Prüfen Sie zunächst die für Ihre installierte PVE-Version dokumentierte OCI-Funktion, sichern Sie persistente Daten und erfassen Sie die bisherige Konfiguration. Erstellen Sie anschließend eine Testinstanz mit dem neuen Image und schalten Sie erst um, wenn Anwendung, Netzwerk und Datenzugriff geprüft sind.

2. Q
   Bleiben Anwendungsdaten nach dem Neuerstellen eines OCI-Containers erhalten?

   Nur Daten, die außerhalb des ersetzten Container-Dateisystems liegen und korrekt eingebunden oder anderweitig gesichert wurden, können unabhängig vom Image erhalten bleiben. Konfiguration, Datenbankdateien und Uploads dürfen nicht als automatisch persistent vorausgesetzt werden. Prüfen Sie die tatsächlichen Mountpoints und testen Sie die Wiederherstellung, bevor Sie die bisherige Instanz entfernen.

3. Q
   Eignet sich ein Proxmox-OCI-Container für einen dauerhaft produktiven Dienst?

   Das hängt davon ab, wie der Dienst aktualisiert und betrieben wird. Eine einfache, stabile Einzelanwendung kann nach erfolgreichem Test in Frage kommen, sofern Daten und Rückweg sauber geplant sind. Bei häufigen Image-Wechseln, mehreren zusammengehörigen Containern oder einem etablierten Compose- und Volume-Workflow sollte eine Container-Laufzeit innerhalb einer VM geprüft werden.

4. Q
   Worin unterscheidet sich ein OCI-Image-Container von Docker in einer VM?

   Proxmox kann OCI-Images als Grundlage für LXC-Container verwenden; daraus folgt aber nicht automatisch die vollständige Docker-Verwaltung samt gewohnter Compose-Abläufe und Container-Laufzeit. Eine VM mit einer darin installierten Container-Laufzeit bietet einen anderen Betriebsweg und eine eigene Systemgrenze. Entscheidend sind benötigte Werkzeuge, Isolation, Datenverwaltung und Updateprozess – nicht ein allgemeiner Leistungssieger.