Anleitung: ZIP zu TAR konvertieren (für Linux-Server-Migrationen)
Warum ZIP und TAR in verschiedenen Welten existieren
ZIP und TAR stammen aus zwei unterschiedlichen Computer-Philosophien. ZIP, 1989 für DOS und Windows entwickelt, kombiniert Archivierung und Komprimierung in einem praktischen Paket. Es behandelt Dateien einzeln, sodass du eine einzelne Datei extrahieren kannst, ohne das gesamte Archiv zu dekomprimieren, und es speichert Metadaten im Windows-Stil. TAR, kurz für Tape ARchive, ist pures Unix. Es macht nur eine einzige Sache: Es kettet Dateien zu einem einzigen Datenstrom aneinander. Das ist alles. Die Komprimierung ist ein separater Schritt, der normalerweise von Tools wie gzip (.tar.gz) oder bzip2 (.tar.bz2) übernommen wird. Dieser Unterschied ist nicht nur akademisch; er hat enorme praktische Auswirkungen bei der Migration von Linux-Servern. Du bekommst ein ZIP von einem Windows-Entwickler oder aus einem cPanel-Backup, und plötzlich kämpfst du beim Deployment mit Berechtigungsfehlern, kaputten Symlinks und verlorenen Metadaten. TAR wurde entwickelt, um genau die Dinge zu erhalten, die ZIP ignoriert: Unix-Dateiberechtigungen (deine `chmod 755` und `644`), Eigentümerdaten, Symlinks und Hardlinks. Es ist ein Lebensretter. Ein häufiger Albtraum ist eine auf Windows gezippte WordPress-Seite. Das `wp-cron.php`-Skript könnte seine Ausführungsberechtigung verlieren, oder wichtige Symlinks könnten zu nutzlosen Dateien plattgemacht werden. Indem du dasselbe Projekt zuerst als .tar.gz neu verpackst, umgehst du all diese Probleme, bevor du es auf deinem Apache- oder Nginx-Server bereitstellst. Die Konvertierung von ZIP zu TAR ist nicht nur eine Geschmacksfrage; sie ist ein notwendiger Schritt für eine reibungslose, vorhersehbare Migration.
Die schnellste Methode: CocoConvert für kleine bis mittelgroße Archive
Wenn du es mit einem Archiv unter 2 GB zu tun hast, ist ein Online-Tool die schnellste Lösung. Jeder, der schon mal eine temporäre VM hochfahren musste, nur um eine einzige Konvertierung durchzuführen, weiß, dass man das Problem manchmal einfach nur jetzt gelöst haben will. Dafür nutzt du die Cloud. Der [ZIP zu TAR Konverter](/convert/zip-to-tar) von CocoConvert erledigt den gesamten Prozess – Extrahieren und neu Verpacken – auf seinen Servern. Du musst absolut nichts installieren. Die Anwendung ist einfach: 1. Gehe zu [cocoConvert.com/convert/zip-to-tar](/convert/zip-to-tar). 2. Ziehe deine .zip-Datei auf die Seite oder benutze den 'Datei auswählen'-Button. 3. Wähle dein Ausgabeformat. Du kannst ein reines .tar, ein komprimiertes .tar.gz oder ein .tar.bz2 erhalten. 4. Klicke auf 'Konvertieren'. Eine 500 MB große ZIP-Datei dauert normalerweise zwischen 30 und 90 Sekunden, je nachdem, wie stark die Server ausgelastet sind. 5. Lade das fertige TAR-Archiv herunter. Du kannst es auf deinem Computer speichern oder mit `wget` und dem bereitgestellten Link direkt auf deinen Server ziehen. Ein schneller Tipp zur Formatwahl: Bei Servern mit knappem Speicherplatz ist .tar.gz die beste Wahl. Es schrumpft textlastige Codebases typischerweise um 60–70 %. Wenn du eine schnellere Dekomprimierung auf älterer Hardware benötigst und eine etwas größere Datei in Kauf nehmen kannst, ist .tar.bz2 eine solide Option, auch wenn die Erstellung länger dauert. Aber seien wir ehrlich, was die Grenzen angeht. CocoConvert ist perfekt für schnelle, einmalige Aufgaben. Es ist nicht für Archive über 2 GB, verschlüsselte ZIP-Dateien oder Situationen ausgelegt, die eine perfekte Erhaltung spezifischer Unix-ACLs (Access Control Lists) erfordern. Für diese anspruchsvollen Aufgaben musst du auf die Kommandozeile ausweichen, was wir als Nächstes behandeln.
Kommandozeilen-Konvertierung unter Linux: Der zuverlässige Weg für große Archive
Für große Archive, Dateien, die sich bereits auf einem Remote-Server befinden, oder alles mit kniffligen Berechtigungen ist die Kommandozeile dein bester Freund. Sie gibt dir die totale Kontrolle. Alles, was du brauchst, sind zwei Dienstprogramme, die auf praktisch jedem Linux-System vorhanden sind: `unzip` und `tar`. Stelle zuerst sicher, dass sie installiert sind: ``` which unzip tar ``` Unter Debian/Ubuntu kannst du sie mit `sudo apt install unzip tar` installieren. Unter RHEL/CentOS/AlmaLinux lautet der Befehl `sudo dnf install unzip tar`. Der Prozess selbst ist einfach: Du entpackst das Archiv in ein temporäres Verzeichnis und packst dieses Verzeichnis dann als TAR-Datei neu. Zuerst das ZIP-Archiv extrahieren: ``` unzip archive.zip -d ./extracted_content ``` Die Verwendung der `-d`-Option ist nicht verhandelbar. Sie erstellt ein dediziertes Verzeichnis für den Inhalt. Wenn du sie vergisst, verteilt `unzip` die Dateien über dein gesamtes aktuelles Verzeichnis und verursacht ein riesiges Chaos, das du von Hand aufräumen musst. Als Nächstes packst du es in ein TAR-Archiv: ``` tar -czf archive.tar.gz -C ./extracted_content . ``` Schlüsseln wir diese Optionen mal auf. `-c` erstellt ein neues Archiv, `-z` fügt gzip-Kompression hinzu und `-f` legt den Namen der Ausgabedatei fest. Die `-C`-Option ist hier der wahre Held: Sie weist `tar` an, in das Verzeichnis `extracted_content` zu wechseln, bevor es mit dem Archivieren beginnt. Der abschließende `.` befiehlt ihm, alles in seinem neuen aktuellen Verzeichnis zu archivieren. Dieser kleine Trick verhindert, dass du eine zusätzliche, unerwünschte Verzeichnisebene in deinem Archiv erhältst – ein klassischer Fehler, der Deployment-Pfade zerstören kann. Brauchst du eine andere Kompression? Für .tar.bz2 tausche einfach `-z` gegen `-j` aus: ``` tar -cjf archive.tar.bz2 -C ./extracted_content . ``` Und wenn deine Dateien bereits komprimiert sind (wie Bilder oder Videos), kannst du ein reines, unkomprimiertes TAR-Archiv erstellen: ``` tar -cf archive.tar -C ./extracted_content . ``` Bevor du das temporäre Verzeichnis löschst, solltest du immer eine kurze Plausibilitätsprüfung durchführen, um sicherzustellen, dass das Archiv gültig ist: ``` tar -tzf archive.tar.gz | head -20 ``` Dieser Befehl listet die ersten 20 Dateien auf. Wenn die Struktur richtig aussieht, bist du startklar.
Dateiberechtigungen und Eigentümer während der Migration handhaben
Pass hier gut auf, denn das ist der Schritt, bei dem die meisten ZIP-zu-TAR-Migrationen scheitern. Das Problem sind die Berechtigungen. ZIP hat ein 16-Bit-Feld für Dateiattribute, aber dessen Interpretation ist zwischen den Betriebssystemen extrem inkonsistent. Ein ZIP von macOS mag es richtig machen, aber ein ZIP vom Standard-Archivierungsprogramm von Windows wird es mit ziemlicher Sicherheit falsch machen. Wenn du `unzip` unter Linux ausführst, versucht das Tool sein Bestes, die Berechtigungen zu erraten. Normalerweise vergibt es standardmäßig 644 für Dateien und 755 für Verzeichnisse, basierend auf der `umask` deines Systems (die typischerweise 022 ist). Während das für die meisten Web-Assets in Ordnung ist, ist es ein K.o.-Kriterium für jedes Skript, das Ausführungsberechtigungen benötigt. Die einzig zuverlässige Lösung ist, die Berechtigungen selbst zu korrigieren, *bevor* du das TAR-Archiv erstellst. Überprüfe und korrigiere sie mit `find`: ``` # Setze alle Dateien auf einen sicheren Standardwert (644) find ./extracted_content -type f -exec chmod 644 {} \; # Setze alle Verzeichnisse auf einen sicheren Standardwert (755) find ./extracted_content -type d -exec chmod 755 {} \; # Mache Skripte explizit ausführbar find ./extracted_content -name '*.sh' -exec chmod 755 {} \; ``` Die Eigentümerschaft ist die andere Hälfte des Puzzles. Wenn du eine Web-App umziehst, müssen die Dateien wahrscheinlich dem Benutzer `www-data` (unter Debian/Ubuntu) oder `nginx` bzw. `apache` (auf RHEL-Systemen) gehören. Lege die Eigentümerschaft fest, bevor du das Archiv erstellst, besonders wenn ein Deployment-Skript davon abhängt: ``` sudo chown -R www-data:www-data ./extracted_content ``` TAR bewahrt die Eigentümer- und Berechtigungsinformationen originalgetreu so, wie sie im Moment der Archiverstellung existieren. Wenn du sie vorher richtig einstellst, wird dein Deployment zu einem einfachen Extrahieren – keine unsauberen `chmod`-Skripte mehr nach der Bereitstellung. Für automatisierte Deployments ist das ein gewaltiger operativer Vorteil gegenüber dem Herumärgern mit ZIP-Dateien.
Die ZIP-zu-TAR-Konvertierung in Migrationsskripten automatisieren
Wenn du mehr als eine Datei konvertierst, automatisiere den Prozess. Egal, ob du Dutzende von Websites migrierst oder nur wöchentliche ZIP-Backups von einem cPanel-Server verarbeitest, ein Skript wird dir eine Menge Zeit sparen und einfache Fehler verhindern. Dieses Shell-Skript ist ein großartiger Ausgangspunkt. Es findet jede ZIP-Datei in einem Quellverzeichnis, konvertiert sie und legt die resultierende TAR-Datei in einem Zielverzeichnis ab. ```bash #!/bin/bash SOURCE_DIR="/srv/backups/zip" DEST_DIR="/srv/backups/tar" TMP_DIR="/tmp/zip_conversion" mkdir -p "$DEST_DIR" "$TMP_DIR" for zipfile in "$SOURCE_DIR"/*.zip; do basename=$(basename "$zipfile" .zip) extract_path="$TMP_DIR/$basename" echo "Processing: $basename" mkdir -p "$extract_path" unzip -q "$zipfile" -d "$extract_path" # Fix permissions find "$extract_path" -type f -exec chmod 644 {} \; find "$extract_path" -type d -exec chmod 755 {} \; tar -czf "$DEST_DIR/${basename}.tar.gz" -C "$extract_path" . # Verify before cleanup if tar -tzf "$DEST_DIR/${basename}.tar.gz" > /dev/null 2>&1; then echo "Success: ${basename}.tar.gz" rm -rf "$extract_path" else echo "ERROR: Conversion failed for $basename" >&2 fi done rm -rf "$TMP_DIR" ``` Um es zu verwenden, speichere den Code als `convert_zips.sh`, mache es mit `chmod 755 convert_zips.sh` ausführbar und führe es dann mit `./convert_zips.sh` aus. Beachte die Sicherheitsprüfung: Das Skript überprüft, ob das neue TAR-Archiv lesbar ist, bevor es die temporär extrahierten Dateien löscht. Das ist ein entscheidender Schritt, der verhindert, dass du versehentlich Daten verlierst, falls während des `tar`-Befehls etwas schiefgeht. Um dies automatisch auszuführen, füge es einfach einem Cronjob hinzu. Dieses Beispiel führt das Skript jeden Tag um 2 Uhr morgens aus und protokolliert die gesamte Ausgabe: `0 2 * * * /srv/scripts/convert_zips.sh >> /var/log/zip_conversion.log 2>&1`.
Häufige Fehler und wie du sie behebst
Früher oder später wird eine Konvertierung fehlschlagen. Das passiert. Hier sind die häufigsten Fehler, auf die du bei der Konvertierung von ZIP zu TAR stoßen wirst, und wie du sie überwindest. **'End-of-central-directory signature not found'** Das bedeutet fast immer, dass deine ZIP-Datei beschädigt oder unvollständig ist. Vergleiche ihre Größe mit der Originalquelle und versuche, sie erneut herunterzuladen. Als letzte Rettung kannst du versuchen, sie zu reparieren: `zip -FF corrupted.zip --out repaired.zip` **'Cannot allocate memory' während unzip** Hier geht es normalerweise nicht um den Arbeitsspeicher (RAM), sondern um File Descriptors. Ein Archiv mit Millionen winziger Dateien kann das Systemlimit ausschöpfen. Erhöhe das Limit für deine aktuelle Shell-Sitzung mit `ulimit -n 65536` und versuche es erneut. **Symlinks fehlen im TAR** Wenn deine Symlinks zu reinen Textdateien werden, die den Link-Pfad enthalten, verwendest du möglicherweise eine alte Version von `unzip`, die damit nicht umgehen kann (einige Versionen erforderten die `-X`-Option). Überprüfe dies mit `unzip -v` und führe ein Upgrade durch, wenn du eine Version vor 6.0 verwendest. Eine robustere Alternative ist die Verwendung des `zipfile`-Moduls von Python, das Symlinks hervorragend beibehält: `python3 -c "import zipfile; zipfile.ZipFile('archive.zip').extractall('extracted/')"`. **Dateinamen mit Leerzeichen bringen tar durcheinander** Ah, das klassische Problem mit Leerzeichen in Dateinamen. Das kann einfache `find`-Befehle zur Korrektur von Berechtigungen aus dem Tritt bringen. Die kugelsichere Methode, damit umzugehen, ist die `-print0`-Option von `find` in Kombination mit `xargs -0`: `find ./extracted_content -type f -print0 | xargs -0 chmod 644` **Archiv zu groß für /tmp** Viele Systeme konfigurieren `/tmp` als `tmpfs`-Partition im RAM, oft begrenzt auf die Hälfte deines Gesamtspeichers. Wenn dein Archiv riesig ist, wird der Vorgang fehlschlagen. Du kannst `unzip` entweder anweisen, ein anderes temporäres Verzeichnis auf einer echten Festplatte zu verwenden (`export TMPDIR=/var/tmp`), oder, noch besser, einfach direkt mit der `-d`-Option einen festplattenbasierten Extraktionspfad angeben. **CocoConvert-Timeout bei großen Dateien** Unser Web-Tool ist auf Komfort ausgelegt, nicht auf riesige Dateien. Alles über 2 GB wird wahrscheinlich zu einem Timeout führen. Das ist eine harte Grenze für die meisten browserbasierten Uploads. Für große Aufgaben musst du die Kommandozeilenmethode verwenden.
Die richtige TAR-Kompression für deine Serverumgebung wählen
Die Kompression, die du mit TAR kombinierst, ist nicht nur ein Detail; sie beeinflusst die Migrationsgeschwindigkeit, die Festplattennutzung und sogar die Serverleistung während des Deployments. Hier erfährst du, wie du die richtige auswählst. **.tar.gz (gzip)** Das ist nicht ohne Grund der Industriestandard. Es bietet ein gutes Kompressionsverhältnis (normalerweise 3:1 bis 5:1 bei Code), dekomprimiert schnell (ein 1 GB großes .tar.gz entpackt sich auf einem modernen Server in etwa 15 Sekunden) und wird universell unterstützt. Mein Rat? Nimm einfach das. Sofern du keinen sehr spezifischen, zwingenden Grund hast, etwas anderes zu wählen, ist .tar.gz die richtige Antwort. **.tar.bz2 (bzip2)** Damit erhältst du eine Datei, die etwa 10–15 % kleiner ist als bei gzip, aber zu einem hohen Preis: Die Komprimierung ist 3–4x langsamer. Auch die Dekomprimierung ist langsamer. Das ist ein Kompromiss, der nur für die Langzeitarchivierung sinnvoll ist, bei der jedes Gigabyte zählt, nicht für aktive Deployments. **.tar.xz (xz/LZMA)** Dieses Format bietet die beste Kompression und schrumpft Quellcode oft 20–30 % stärker als gzip. Aber die Dekomprimierung ist langsam und ein Speicherfresser – ein 500 MB großes .tar.xz kann leicht 700 MB RAM allein zum Entpacken beanspruchen. Du solltest dies für Migrationen vermeiden, besonders wenn du auf einem Server mit begrenzten Ressourcen arbeitest. **.tar (ohne Kompression)** Komprimiere nichts, was bereits komprimiert ist. Wenn dein Archiv voller JPEG-Bilder, MP4-Videos oder vorkomprimierter Datenbank-Dumps ist, ist das Verpacken in gzip reine Verschwendung von CPU-Zyklen für einen Größenvorteil nahe null. In diesem Fall ist ein reines .tar die effizienteste Wahl. Für fast jede web-bezogene Migration – PHP-Anwendungen, Node.js-Projekte oder Python-Codebases – ist .tar.gz der richtige Weg. Es ist das, was Deployment-Tools wie Capistrano, Deployer und das `unarchive`-Modul von Ansible erwarten, und es trifft genau den Sweet Spot aus Geschwindigkeit, Größe und Kompatibilität. Wenn du eine einmalige Konvertierung durchführst und dich nicht mit den Details von Kommandozeilen-Optionen herumschlagen willst, bietet dir der [ZIP zu TAR Konverter](/convert/zip-to-tar) von CocoConvert die praktischsten Optionen – .tar, .tar.gz und .tar.bz2 – direkt im Browser. Das ist eine gute Abkürzung, wenn die Arbeit einfach nur erledigt werden muss.