Synology DiskStation: Große Dateien splitten und in Einzelteilen laden

Sebastian8 KommentareSynologyDiskStation, Synology

Quicktipp: Ich bin derzeit recht viel unterwegs und nicht immer habe ich stabiles Internet – das kennt ihr bestimmt auch. Nun brauchte ich jedoch eine relativ große Datei, die ich mit der lahmen Verbindung einfach nicht downloaden konnte, weil die Internetverbindung ständig abgerissen ist. Bei einer Datei mit knapp 2 GByte und einer durchschnittlichen Downloadgeschwindigkeit von ca. 400 KByte/s ist das wirklich kein Spaß.

Die DiskStation als Retter

Dann fiel mir ein: die DiskStation läuft immer. Kann die nicht dabei helfen? Klar.

Also hab ich die DiskStation die Datei laden lassen, sie anschließend mit ZIP gepackt und dann wiederum in kleine Teile splitten lassen. Nun konnte ich die kleinen Dateien einzeln von der DiskStation ziehen. Beim Verbindungsabbruch musste ich also nicht komplett von vorne beginnen, sondern konnte bei dem Teil weitermachen, bei dem der Download abgebrochen ist.

Dateien zippen und in Teile zerlegen

Man kann über die Weboberfläche des DSM Dateien mit ZIP oder 7Zip packen (in der File Station rechte Maustaste auf die Datei -> Zu Archiv hinzufügen…), allerdings wird keine Option zum Splitten des Archivs angeboten. ZIP bietet zwar auf der Kommandozeile die Möglichkeit, mit zip -s <Größe> ... ein Archiv direkt zu zerteilen, allerdings wird das Zusammensetzen und Extrahieren der Einzelteile nicht richtig unterstützt und funktioniert auch nicht immer. Daher bemühen wir per SSH die Kommandozeile und machen das manuell. Zuerst packen…

$ zip <Zielarchiv> <Datei/Ordner>

…und anschließend splitten:

$ split -b <Größe> <Quelldatei> "<Zieldatei>.part"

Die Größe wird nach folgendem Schema angegeben:

  • 5K (=5 KByte)
  • 5M (=5 Mbyte)
  • 5G (=5 GByte)
  • 5T (=5 TByte)

In meinem Fall sah die Befehlszeile dann so aus:

$ split -b 50M ubuntu-18.04.1-desktop-amd64.zip "ubuntu.part"

Im Ergebnis hab ich 37 Teile mit der Dateiendung .partaa...partbi bekommen, die ich nun einzeln auf meinen Rechner laden konnte.

Zusammensetzen funktioniert ebenso einfach. Unter macOS oder Linux nutzen wir cat:

$ cat ubuntu.part* > ubuntu-18.04.1-desktop-amd64.zip

Unter Windows tut echo genau das gleiche:

> echo ubuntu.part* > ubuntu-18.04.1-desktop-amd64.zip

Am Ende haben wir die ursprüngliche ZIP-Datei erhalten, die wir nun ganz normal entpacken können.

Weiterführende Links

Sebastian
Letzte Artikel von Sebastian (Alle anzeigen)

8 Comments

  1. Antworten sp33dhntr

    Hallo, ich habe dasselbe Problem mit der Verbindung, nur schaffe ich mit deiner Anweisungen keine Archive zu komprimieren. Ich bekomme nur eine Archive mit etwa 200 Byte uns sonst nichts. Was mache ich falsch?

    • Antworten Sebastian

      Keine Ahnung, denn du schreibst ja nicht, was du überhaupt gemacht hast.
      Also, wie gehst du konkret vor und wie sehen die Zwischenergebnisse aus?

      • Antworten Sp33dhntr

        Danke für deine schnelle Antwort Sebastian. Stimmt, meine Schuld.
        Also, ich habe mich gestern per ssh mit meinem admin account eingeloggt und versucht, die commands, die du hier angegeben hast wie du sie geschrieben hast einzutippen. Die genaue Fehlermeldungen weiss ich jetzt leider nicht mehr, aber das Maximum, was ich erreicht habe war ein zip file von ungefähr 200Byte, der einfach so gespawnt wurde und sonst nichts. Ich habe aber heute neu versucht und zwar so:

        eingeloggt mit meinem account
        sudo -i
        danach zip herstellt mit
        zip /volume1/Cloud/file.zip "/volume2/Backup/Backup MacBook Pro.sparsebundle"
        diesmal hat es geklappt und wurde ein zip Archive auf dem Volume 1 hergestellt
        dann mit
        split -b 5G /volume1/Cloud/file.zip backup.part habe ich die Fehlermeldung bekommen „split: backup.partaa: No space left on device“ obwohl ich noch 1TB auf diesem Volume frei habe, also hab versucht mit voller path
        split -b 5G /volume1/Cloud/file.zip /volume1/Cloud/backup.part
        hab zwar keine Meldungen bekommen, aber in der File Station sehe ich 5GB grosse Teile die herstellt werden, hat also geklappt.

        Ich muss etwas falsch mit den File Path gemacht haben, sonst war deine Anleitung richtig, ausser dass die Buchstaben für die Teilfilegrosse beim command split -b grossgeschrieben werden müssen, sonst werden sie nicht erkannt

        Also muss mich nur noch bei dir bedanken, hab sonst nirgendwo gefunden, wie das zippen und splitten gehen sollte!

        • Antworten Sebastian

          Du hast recht mit der Großschreibung. Bei mir hatte das damals zwar funktioniert, aber der Artikel ist erst im Nachgang entstanden, daher war mir das nicht aufgefallen.
          Danke für den Hinweis, ich habe den Beitrag entsprechend angepasst.

  2. Antworten Sp33dhntr

    So einfach war es auch nicht…
    Als ich den vorherigen Post geschrieben habe war meine DiskStation am Splitten. Was gefolgt hat ist:

    Ich wurde aus der Sitzung in der Weboberfläche rausgeschmissen
    Konnte mich nicht mehr einloggen, da „der Speicher derzeit voll ist“
    Sobald ich per ssh das Vorliegen aller Teildateien bestätigt habe habe ich durch „reboot“ die Maschine neu gestartet.
    Konnte mich weder in der Weboberfläche (Speicher voll) noch per ssh (permission denied) anmelden.
    War total blockiert aus meiner NAS…
    Habe also ein Support ticket geöffnet, und das Sachverhalt geschildert. Der Mitarbeiter hat mir gebeten, die Maschine auszuschalten, HDDs rauszunehmen, wieder einschalten, einen Skript durch Besuch einer Webpage auf dem NAS IP auszuführen, um telnet zu aktivieren, HDDs wieder einschieben. Das Zweck war remote access durch den Mitarbeiter via Telnet zu ermöglich, damit er die System Partition von bestimmte file befreien könnte, was er auch gemacht hat (und zwar bestimmte Zippartdataeien, die auf diese Partition „zwischengelagert wurden“. Nach einem Reboot musste ich aber DSM neu installieren und habe folgendermassen alle Einstellungen verloren, zum Glück aber keine Dateien.
    Support: „Ich habe die entsprechende 1.4GB Zip Part Datei auf der Systempartition gelöscht.“

    Antworten von der Mitarbeiter auf meine Frage, wie das alles möglich, obwohl ich noch fast 1TB auf dem volume1 frei hatte:

    „Vermeidung des Problems: Auch wenn sie da per SSH die ZIP Datei von Volume 1 auf Volume 2 kopiert haben, wird ein Teil der ZIP Datei auf der System partition zwischengelagert und diese läuft somit voll.
    Ich rate einfach die Dateien per File Station zu kopieren – für die Zukunft.“
    „das von ihnen per SSH durchgeführte Kommando (split) wird nicht unterstützt und das Verhalten ist also nicht vorhersehbar.“
    „Ein Löschen von Dateien in der Systempartition kann zum nicht mehr starten des Systems führen. In ihrem Fall war die Part Datei in /root“

    Mir scheint einfach eine Ablenkung von der Tatsache, das hier ein Bug vorliegt, kann ja nicht sein, dass durch ein so simple Kommando die ganze Maschine (DS918+) unbrauchbar geht. Was hältst du davon?

    • Antworten Sebastian

      Ich kenne das Problem, dass man sich nicht mehr einloggen kann, wenn der Speicher voll ist. Mir selber ist das noch nicht passiert, aber in den Foren liest man ja ab und zu davon.
      Aber dass das jetzt daran gelegen haben soll, dass du per SSH eine Datei kopiert hast, finde ich schon komisch.
      Ausschließen kann ich das jedoch nicht und letztlich wäre es ja auch denkbar, dass du dich da irgendwie vertan hast, oder? 😉

      Aber mal im Ernst: die Kommandozeile ist bei Synology schon immer etwas tricky und tatsächlich auch nicht ganz frei von Bugs. Daher sollte man da auch sehr vorsichtig sein.
      Vielleicht sollte man auch die Split-Teile kleiner machen. Wenn die gelöschte Datei 1,4GB groß war als Speicher vollgelaufen ist, könnte man ja daraus schlussfolgern, dass das speziell in deinem Fall nicht passiert wäre, wenn du die vielleicht nur 1GB groß gemacht hättest. Dann hätte der Vorgang abgeschlossen und die nächste Datei verarbeitet werden können. Aber das ist nur eine Vermutung.

      • Antworten Sp33dhntr

        Ich habe auch es in den Foren entdeckt, als ich nach dem Fehler gesucht habe, es lag fast immer aber daran, dass plötzlich eine Logmenge erstellt wurde (und sowieso in älteren Versionen). Nach einer Serie von SSH Kommanden habe nichts gefunden.
        Es könnte schon sein, dass ich mich dabei vertippt habe, aber die Kommanden, die ich hier oben gepostet habe, habe ich mit cmd+C von der Terminal Shell herauskopiert, so sollte mindestens sichtbar sein, wo ich mich vertan hätte…
        Dass 5 GB Grösse ein Problem darstellen könnte, ist mir wirklich nicht im Sinn gekommen Das komische ist aber, dass ich tatsächlich alle Teile im volume1/Cloud/ jetzt sehen kann und dementsprechend korrekt erstellt wurden. Vielleicht liegt auch daran, dass ich nur 4GB RAM installiert habe…
        Zumindest habe ich keine Dateien verloren, das ist schon etwas. Ende gut alles gut. Auch heute etwas gelernt

        • Antworten Sebastian

          Man kann da sicher viel spekulieren und mir stellen sich gerade noch zwei Fragen:
          1. Wäre das auch passiert, wenn das Ziel auf einem anderen Volume gelegen hätte?
          2. Wäre das auch passiert, wenn du ohne root-Rechte gearbeitet hättest?

          Vielleicht kommt ja irgendwann jemand, der das beantworten kann.

          Ich freue mich jedenfalls für dich, dass dein System wieder läuft.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht.

WordPress Cookie Hinweis von Real Cookie Banner