Export vom Container klappt aber Import nicht mehr

[Mirko1]

Hallo,

ich habe ein Problem.
Ich habe zu Dateinsicherungszwecken den Container exportiert.
Jetzt wollte ich diesen nachdem der andere Container gelöscht war diesen wieder importieren.
Leider kommt dann die Fehlermeldung "Import von ......Container.txz fehlgeschlagen, vermutlich auf Grund eines ungültigen Dateiformats. Weitere Informationen fiden Sie im Docker Protokoll." Im Protokoll steht aber auch nur failed drin. Keine meiner Dateinsicherungen kann ich zurückspielen. Gleicher Fehler. Ich hatte den kompletten Container gesichert.

Kann mir jemand helfen?

 

[Mirko1]

Übrigens ist das mit jedem Container so. Ich habe ma einen anderen gesichert und wieder versucht zurück zu sicher. Gleicher Fehler. Was könnte das nur sein?

 

[plang.pl]

Welche DS, welche DSM-Version, welche Docker-Version

 

[Mirko1]

Diskstation 918+,
DSM 7.1.1-42962 Update 4
Docker Version 20.10.3-1308
Alles die neueste Version. Versucht habe ich natürlich auch schon das neu starten der DS.
Im Docker Protokoll steht "Import container from [Passwort-Server-1.syno.txz] failed: [null]"

 

[plang.pl]

Hast du es mal mit einem anderen Browser versucht? Bzw auch von einem anderen Client aus?

 

[haydibe]

Haben die txz-Dateien eine plausible Größe? Alles im KB oder geringen MB Bereich wäre auffällig klein.
Interessant ist, ob die Container-Exporte mit derselben Docker-Package Installation durchgeführt worden, wie die Importe.

 

[Mirko1]

Danke für die Antworten.

@haydibe
Die Größen sind plausibel. 8 MB für Adguard und 35MB für Vaulwarden.
Die Sicherungen habe ich erst heute geamcht. Also ich habe zwischendrin keine Updates gemacht.

@plang.pl
Mit einem anderen Browser habe ich es versucht. Geht auch nicht.

 

[plang.pl]

Das ist nicht plausibel. Allein das Image von AdGuard hat schon mindestens 60MB

 

[Mirko1]

@plang.pl
Ein Freund von mir hat auch ein DS ihm habe ich meine Containerdatei geschickt. Bei ihm kam der gleiche Fehler. Gleichzeitig hat er auch mal einen Export seines Adguard Containers gemacht. Seine Sicherungen sind ähnlich groß. Er kann aber erfolgreich importieren.
Also die Größen sollten stimmen.

 

[plang.pl]

Du hast vermutlich nur die Container-Einstellungen exportiert und nicht explizit den ganzen Container.

 

[Mirko1]

Nein. Die Endung ist doch .txz Wenn ich nur die Einstellungen exportiere sind es .json Dateien die nur paar KB groß sind. Ich sag ja die Dateigrößen stimmen. Das wurde mit einer anderen Diskstation getestet.

 

[plang.pl]

Komisch. Als ich das vor langer Zeit mal in der Art gemacht habe, waren die Exporte immer mehrere 100MB groß.
Mittlerweile lasse ich das und sichere lieber den docker-Share. Da ist alles Relevante drin, wenn die Mappings passen. Und ich umschiffe derartige Probleme.

 

[Mirko1]

@plang.pl Wie genau geht das? Ich habe das Problem das ich eben jetzt gar keine Sicherung erstellen kann die im Notfall funktioniert.

 

[plang.pl]

Naja. Kommt auf den Container an. Steht aber ja in den Anleitungen mit drin.
Im Falle von AdGuard:

docker run -d --name=adguard \
-e TZ=Europe/Berlin\
-v /volume1/docker/adguard/config:/opt/adguardhome/conf \
-v /volume1/docker/adguard/data:/opt/adguardhome/work \
--net=host \
--restart always \
adguard/adguardhome

Dann würden alle Daten unter /volume1/docker liegen.
Im Ernstfall müsstest du die Sicherung also wieder dort hin schieben und den Container mit den ursprünglichen Einstellungen wieder aufsetzen.
Also idealerweise das Script, mit dem du den Container installiert hast (also in dem Fall das obige AdGuard Script), einfach mit in die Sicherung packen als txt-Datei. Dann ist das alles schnell gemacht.

 

[haydibe]

Wer auf Container Export angewiesen ist, muss tatsächlich etwas grob falsch machen.

Der Zustand des Containers sollte egal sein, wenn die relevanten Daten mittels Volume aus dem Container auf einen Share der DS gemapped sind. Dann reicht das Backup der Container Konfiguration + ein Backup des Verzeichnisses wo das Volume in der DS hingemapped ist.

Zur Größe des TXZ-Datei: Der Container Export sollte so groß sein, wie das Container-Filesystem, dass wiederum aus Image-Layern + alle erzeugten und geänderten Dateien ab Image enthält. TXZ-Dateien sind Tarbal-Dateien, die mittels XZ stark komprimiert wurden. Die Werte können also durchaus plausibel sein.

 

[Mirko1]

@plang.pl
Danke erstmal aber das ist für mich eine Nummer zu hoch.

@haydibe
Warum mache ich etwas grob falsch? So hätte ich doch den Container komplett gesichert. Es gibt ja extra diese Funktion. Die geht aber scheinbar bei mir nicht. Jetzt im Ernstfall wo ich es brauche nutzt mir das nichts.
Die Daten habe ich natürlich noch in einem anderen Verzeichnis. Die Sche mit den Volumes und so. Allerdings hatte ich noch den alte BitwardenContainer den es so nicht mehr gibt. Den muss ich erstmal finden.
Dafür habe ich ja den Export gemacht um im Notfall auch mal einen Container einfach wieer herstellen zu können.
Mir gehts jetzt um das Problem das es einfach nicht geht.

 

[plang.pl]

Diese Export-Funktion ist in Docker eigentlich nicht vorgesehen und ist von Synology hingebastelt.
Außerdem bringt dir das alles nix ohne korrekte Mappings. Denn du kannst keine Updates des Containers machen. Dann sind immer alle Daten weg.

 

[haydibe]

Diese Export-Funktion ist in Docker eigentlich nicht vorgesehen und ist von Synology hingebastelt.

Gibt es auch bei Vanilla-Docker. Wobei die Syno-Variante in seiner Umsetzung abweicht.

Warum mache ich etwas grob falsch?

Weil ich es für absolut falsch halte, auf den Zustand eines Containers angewiesen zu sein. Wenn man davon abhängig ist, dann hat man irgendwelche notwendigen Volume-Mappings nicht gemacht. Zustand gehört über Volumes aus dem Container "rausgemapped". Container sind als Wegwerf-Instanzen gedacht und sollten auch als solche behandelt werden. Zumals der Export trotzdem nicht die Daten enthält die über Volumes rausgemapped sind.

Das Container-Filesystem zu exportieren, schafft mehr Probleme als es löst, da (wie @plang.pl schon geschrieben hat) die Relation Image<>Container nicht mehr vorhanden ist, sondern einfach nur das Container-Filesystem exportiert und importiert wurde - die Packages und Anwendung im Container können beliebig alt sein und bleiben es dann auch.

Mir gehts jetzt um das Problem das es einfach nicht geht.

Schon klar. Ich weiß auch nicht, warum es nicht geht. Bei meinen Tests über die CLI damals ging das immer zuverlässig, solange der alte Container weg war, kein anderer Container den Host-Port blockiert hat und alle für Volume-Mappings verwendeten Host-Verzeichnisse noch vorhanden waren.

Man kann generell testen, ob die txz-Datei in Ordnung ist, in dem man auf der Shell dort wo die txz-Datei liegt den Befehl tar -tf Password-Server-1.syno.txz ausführt. Wenn das Archiv heil ist, sollte image.tar und profile.json ausgegeben werden.