Backup - ZIP Archiv - Dateien im Basisverzeichnis viel größer

    Moinsen Leute,


    wollte hier mal nachfragen wie das sein kann, dass ich über die Shell ein Backup mit zip mache und dabei Dateien im Basisverzeichnis erstellt werden, die zusammen um einiges größer sind als die zu archivierenden Dateien.


    Also ich bin dabei meinen Webspace zu wechseln auf ein größeres Produkt.
    Ich habe erstmal über den Plesk Dateimanager versucht die Dateien zu zippen. Hierbei kam ein Fehler, weiß gerade nicht mehr genau welcher. Gehe davon aus, dass aufgrund der Datenmenge (ca 105GB) dieser das nicht mit macht. Habe jetzt dann zur Shell gewechselt und die Archivierung in die ZIP Datei gestartet. Bis jetzt läuft auch alles noch. Jetzt wundere ich mich nur, dass wenn ich im Plesk Dateimanager schaue, dort 4 neue Dateien laufend zusammen mit dem zippen der Dateien bearbeitet werden. Das was mich hierbei stutzig macht, ist die Tatsache, dass diese immer größer werden. Also insgesamt gerechnet viel größer als 105GB.


    zidAiQwb mit 57.5 GB

    ziI0U2OH mit 76.9 GB

    zikIxlxR mit 76.7 GB

    zizlUKKE mit 68.0 GB


    Was hat es mit diesen 4 Dateien auf sich? Warum werden die alle immer größer? Was hat das mit dem Zippen des Ordners mit 105GB zu tun?


    Danke im Voraus

    MfG :)

    Hallo,


    da würde ich mir erst einmal keinen Kopf machen, da es sich um temporäre Dateien handelt, auf das endgültige ZIP-Archiv kommt es an (wobei das je nach Anzahl Dateien, Dateitypen, etc. auch mal größer sein kann als der ursprüngliche Ordner).


    Unter Plesk/Linux würde ich persönlich auch immer auf tar + Komprimierung setzen (gz,xz, …), die dabei entstehenden Archivgrößen sind dann zumindest nicht größer als der Ursprungsordner.

    Zitat von Patrick0815

    Hallo,


    da würde ich mir erst einmal keinen Kopf machen, da es sich um temporäre Dateien handelt, auf das endgültige ZIP-Archiv kommt es an (wobei das je nach Anzahl Dateien, Dateitypen, etc. auch mal größer sein kann als der ursprüngliche Ordner).


    Unter Plesk/Linux würde ich persönlich auch immer auf tar + Komprimierung setzen (gz,xz, …), die dabei entstehenden Archivgrößen sind dann zumindest nicht größer als der Ursprungsordner.

    Okey, dass die Archive auch teils größer sein können ist mir bewusst. Mich wunderte es nur, da mit Mal 4 Dateien mit der Größe entstanden sind und ich in dem Hosting auch nur 250 GB habe. Ist etwas verwirrend. Jetzt sind auch 2 Stück weg und nur noch zidAiQwb mit 83.7 GB und zizlUKKE mit 92.9 GB vorhanden. Hab ich so tatsächlich noch nie gesehen, dass dabei diese Dateien erzeugt werden und dann noch gleich 4 Stück mit der Größe :D
    Hab jetzt mit Plesk und dem Webhosting auch noch nicht solche großen Archive gepackt. Kommt ja normalerweise auch nicht ganz so oft vor, jenachdem was man so veranstaltet :P und auf einem Root Server läuft das dann wohl eher im Hintergrund, was man dann nicht so offensichtlich in der Shell sieht.


    Bin auf jeden Fall mal gespannt, was dabei gleich rum kommt. Sollte hoffentlich gleich erfolgreich fertig sein. Dann muss ich nur schauen, wie ich das in das andere Hosting geschoben bekomme. Werde mir die Datei dann wahrscheinlich erstmal auf dem Root Server sichern und dann schauen wie ich das mache.


    ZIP war gerade einfach die Möglichkeit die mir so spontan eingefallen ist.


    Danke für die schnelle Antwort. ;)

    Update:

    Die Dateien sind wieder weg (da hab ich schon mit gerechnet) und die Datei am Ende ist jetzt 100GB (da war ich mir nicht sicher).

    Hat also anscheinend erfolgreich funktioniert. Weiß ich auf jeden Fall fürs nächste Mal bescheid, dass ich mir keine Sorgen um den Speicherplatz und das abbrechen des Shell Befehls machen muss und offensichtlich auch keine Probleme bei so großen Archiven.

    Beruhigt mich ja ^^


    Dann hilft das Thema ja vielleicht trotzdem irgendwem der sich auch solche Gedanken macht. 8o:thumbup:

    Ein wening aufpassen solltest du aber - wenn du über den Limit bist, sperrt Netcup das Hosting (wenn du Pech hast sofort)

    Okey, meinst du das ZIP nicht alles mit gesichert hat wegen dem Speicher oder einfach allgemein das da was fehlen kann? Hab die Daten noch auf dem Webhosting sowie das ZIP. Habe das ZIP dann auch mit knackigen 400 MegaByte/s 8| auf das neue Webhosting geschoben und zusätzlich wollte ich das nochmal auf meinem Root Server sichern, bis ich alles auf dem neuen Hosting eingerichtet und am laufen habe. Bis dahin behalte ich die Dateien noch. Habe auch noch einiges an Zeit, bis ich den Vertrag kündige. Hab das extra früh genug gemacht, da ich auch im Moment nicht immer so viel Zeit habe das alles Recht schnell umzusetzen.

    Danke noch für den Hinweis.

    Bin da mittlerweile ziemlich vorsichtig geworden. Unter Windows hab ich mir da früher schon einige Patzer erlaubt, die dann einiges an privaten Daten gekostet haben. War ziemlich ärgerlich. Seitdem schaue ich meist 2-3 Mal extra drauf ob alles da ist :D

    Zitat von X-Nightmare-X

    Okey, meinst du das ZIP nicht alles mit gesichert hat wegen dem Speicher oder einfach allgemein das da was fehlen kann? Hab die Daten noch auf dem Webhosting sowie das ZIP. Habe das ZIP dann auch mit knackigen 400 MegaByte/s 8| auf das neue Webhosting geschoben und zusätzlich wollte ich das nochmal auf meinem Root Server sichern, bis ich alles auf dem neuen Hosting eingerichtet und am laufen habe. Bis dahin behalte ich die Dateien noch. Habe auch noch einiges an Zeit, bis ich den Vertrag kündige. Hab das extra früh genug gemacht, da ich auch im Moment nicht immer so viel Zeit habe das alles Recht schnell umzusetzen.

    Danke noch für den Hinweis.

    Bin da mittlerweile ziemlich vorsichtig geworden. Unter Windows hab ich mir da früher schon einige Patzer erlaubt, die dann einiges an privaten Daten gekostet haben. War ziemlich ärgerlich. Seitdem schaue ich meist 2-3 Mal extra drauf ob alles da ist :D

    Du hättest die Daten z.B. auch per FTP transferieren können

    Zitat von X-Nightmare-X

    Okey, meinst du das ZIP nicht alles mit gesichert hat wegen dem Speicher oder einfach allgemein das da was fehlen kann?

    Ich halte es bei solch knappen Grenzen durchaus für möglich, dass der Platz kurzzeitig vollgelaufen ist und dein zip evtl. korrupte Daten beinhaltet.

    Zitat von ASS

    Ich halte es bei solch knappen Grenzen durchaus für möglich, dass der Platz kurzzeitig vollgelaufen ist und dein zip evtl. korrupte Daten beinhaltet.

    Aber die Platten laufen ja nicht wirklich voll - sonst gäbe es ja die ganze Speer Problematik nicht - z.B. nach Nextcloud sind noch mehrere TB auf der Platte frei - das Limit meines Webhosting liegt aber bei 400GB - wenn ich das überschreite wird das Hosting gesperrt, die Platte an sich hat aber noch Platz

    Zitat von ASS

    Ah, ich hatte dich so verstanden, dass dein Limit bei 250 läge.

    Ich würde trotzdem vor dem Löschen md5 Summen der Originaldateien bilden und mit denen der Zieldateien vergleichen.

    War nicht direkt auf diesen Fall bezogen - sonder eher allgemein aufs Netcup Webhosting - also das die Platte nicht überläuft.


    Eine eine MD5 Check würde ich aber auch machen

    Zitat von ASS

    Es genügt ja, dass du in ne hard Quota reinläufst.

    Ich erzeuge aber solche Archive nach Möglichkeit eh nicht lokal, sondern pipe die durch ein ssh oder rsync.

    Gibt ja keine Hard Quote(zumindest nicht so wie es sein sollte) - sobald rüber wird das ganze Hosting gesperrt (sobald es erkannt wirst bis dahin kannst du die gesamte Festplatte nutzen) - dann bekommst du auch keine ZIP mehr runter

    Zitat von tom434

    Du hättest die Daten z.B. auch per FTP transferieren können

    Meinst du direkt von Server zu Server?

    Wenn du am PC meinst, finde ich das naja etwas unpraktisch bzw. Mehraufwand. Da ich die Dateien erstmal runter laden müsste und dann wieder hoch laden. Außerdem hab ich gerade nicht Mal 105GB frei. Darum muss ich mich auch noch kümmern. Viel zu viel an Daten auf dem PC. Also download und Upload vom Server zum PC und zum anderen Server wieder uploaden ist denke ich mehr Aufwand als einfach direkt von Server zu Server mit ZIP. Kenne das, dass es bei anderen Hostern die Möglichkeit gibt das direkt über deren Control Panel einzuleiten oder direkt den ganzen Host hin und her zu schieben. Ist auch ganz praktisch aber ist mir bei NetCup so in der Art nicht bekannt.

    Zitat von ASS

    Ich halte es bei solch knappen Grenzen durchaus für möglich, dass der Platz kurzzeitig vollgelaufen ist und dein zip evtl. korrupte Daten beinhaltet.

    Naja sagen wir Mal so, ich hab 250GB wovon halt 105GB belegt sind und bisschen Kleinkram drum herum.

    Dass daraus temporäre Dateien, irgendwas um die 300GB entstehen, da kann ich ja nicht direkt was für.Theoretisch war ich dann mit 105GB plus Archiv von 100GB im Limit drin. Aber hatte damit auch gerechnet, dass hier Probleme entstehen können. Deswegen ja überhaupt der Thread, ob das normal ist.

    Müsste dann nicht eigentlich auch eine Rückmeldung über Fehler in der Shell kommen?


    Zitat von tom434

    Aber die Platten laufen ja nicht wirklich voll - sonst gäbe es ja die ganze Speer Problematik nicht - z.B. nach Nextcloud sind noch mehrere TB auf der Platte frei - das Limit meines Webhosting liegt aber bei 400GB - wenn ich das überschreite wird das Hosting gesperrt, die Platte an sich hat aber noch Platz

    Ja die Platten, je nach Server, haben wohl einiges an GB bzw. TB aber das Serverlimit kann ja dann einschreiten und sagen, ne ist nicht. Bei einem anderen recht bekanntem Hoster der halt nur Webseiten macht, war das so, dass man den Speicherplatz überschreiten konnte, somit waren alle Schreibvorgänge und der Webspace an sich Safe, sodass keine Fehler entstehen konnten. Doch danach wurde man vom Support angeschrieben, sich bitte darum zu kümmern um wieder unter das Limit zu kommen oder einen größeren Tarif zu buchen. Die waren sehr Kulant was das an ging.

    Zitat von ASS

    Ah, ich hatte dich so verstanden, dass dein Limit bei 250 läge.

    Ich würde trotzdem vor dem Löschen md5 Summen der Originaldateien bilden und mit denen der Zieldateien vergleichen.

    Achtung, anderer User. Mein Limit liegt bei 250GB.

    Wie bilde ich denn die Hashs der Dateien bzw. Ordner und vergleiche die am besten?

    Wüsste gerade nicht wie ich 105GB automatisiert Vergleiche.


    Zitat von ASS

    Es genügt ja, dass du in ne hard Quota reinläufst.

    Ich erzeuge aber solche Archive nach Möglichkeit eh nicht lokal, sondern pipe die durch ein ssh oder rsync.

    Damit kenne ich mich noch nicht so aus. Ist tatsächlich in dem Fall oder der Art die erste Sicherung und Umzug in der Größe.

    Müsste ich mich drüber einlesen.

    Müsste auch Mal schauen, wo ich mir gerade nicht sicher bin, wie man Befehle im Hintergrund laufen lässt. Hab ich tatsächlich auch noch nicht so gebraucht. Sonst habe ich einfach Screen benutzt, wenn etwas länger gedauert hat und ich das dann später wieder aufgegriffen habe 😅

    Zitat von tom434

    Gibt ja keine Hard Quote(zumindest nicht so wie es sein sollte) - sobald rüber wird das ganze Hosting gesperrt (sobald es erkannt wirst bis dahin kannst du die gesamte Festplatte nutzen) - dann bekommst du auch keine ZIP mehr runter

    Hmm auch nicht gerade praktisch oder Benutzerfreundlich.

    Also das man bei X GB drüber irgendwann sperrt, ok aber vorher vielleicht noch Mal melden bevor man das macht. Und dann das gesamte Hosting sperren finde ich auch relativ..


    Naja man muss halt auf der anderen Seite schauen, nur seinen Anteil zu benutzen. Ist halt wie es ist 😂


    MfG

    Zitat von X-Nightmare-X

    ok aber vorher vielleicht noch Mal melden bevor man das macht.

    Du kriegst ja 5 Minuten vorher einen Anruf. Auch wenn der dich nicht erreicht und auch nicht in deinem Log auftaucht... :)

    (Sarkastischer Running Gag...) Hat sich eigentlich schonmal irgendwer gemeldet, der diesen ominösen Anruf wirklich erhalten hat?

    Zitat von X-Nightmare-X

    Meinst du direkt von Server zu Server?

    Ja, du kannst auch in der Shell ftp Verbindungen aufmachen.

    Und für Windows gibts auch zb Cyberduck.


    Zitat von X-Nightmare-X

    Müsste dann nicht eigentlich auch eine Rückmeldung über Fehler in der Shell kommen?

    Ja, theoretisch. Aber der Teufel ist ein Eichhörnchen. :)

    Zitat von X-Nightmare-X

    Wie bilde ich denn die Hashs der Dateien bzw. Ordner und vergleiche die am besten?

    Stichwort md5sum

    https://wiki.ubuntuusers.de/md5sum/


    Zitat von X-Nightmare-X

    Sonst habe ich einfach Screen benutzt, wenn etwas länger gedauert hat und ich das dann später wieder aufgegriffen habe

    Ist auch nicht die schlechteste Methode...

    Also wenn ich das letztens richtig verstanden habe, dann wird nicht gleich gesperrt, wenn man ein paar GB über dem Limit ist. Der andere Fall, der hier letztens auflief, wurde gesperrt, als er mehr als 150% des Limits an Speicher belegt hat. Gemessen wird das nur einmal am Tag, die Warnmeldung geht wohl nur bei 80% <= aktueller "Füllstand" <= 100% raus. Das funktioniert bei langsamem Anstieg der Speichernutzung passabel, bei schnellem Anstieg leider gar nicht. Dass offenbar keine Warnmeldung kommt, wenn man am Tag davor bei 79% war und beim nächsten Check schon bei 101%, das ist natürlich suuuuper :D:D;( ... ungünstig und ein grobes Übersehen möglicher Speicherverläufe. Das muss natürlich rasch korrigiert werden, hoffentlich ist es schon korrigiert :rolleyes:. Sollte auch nicht mehr als 1 MM Arbeit sein :D;), eher im Minutenbereich. In dem beschriebenen Extremfall hätte das freilich auch nichts gebracht, da hilft nur eine engmaschigere Überwachung.


    Mehr als 20% des Limits Anstieg an einem Tag klingt viel, ist aber sehr leicht möglich, auch wenn es mal nicht ein rasant überlaufendes Logfile ist. Hätte man den Brüller nicht eingebaut sondern würde grundsätzlich IMMER bei über 80% die Warnmeldung schicken, auch (und gerade!) wenn das Speicherlimit schon überschritten ist, dann hätte man wenigstens etwas mehr Luft, also es kracht nur bei >70% des Limits Anstieg binnen 24 Stunden, so waren es eben >20% und es kam nicht mal eine Warnmeldung. Würde man wenigstens stündlich messen, wäre selbst bei dem Extremfall mit 50% pro Tag wahrscheinlich nichts passiert. Obwohl, wer liest nachts schon Warnmeldungen per E-Mail? Naja, ich gelegentlich ;) .


    Aber das kann man nicht wirklich von einem Kunden erwarten. Also wird man Sperren nicht komplett vermeiden können. Aber wenn man z.B. eine Möglichkeit zum Löschen von Dateien schaffen würde, die nicht gesperrt wird und somit auch am Wochenende genutzt werden kann, würde das die Sache schon etwas entspannen. Und würde man auch noch automatisch entsperren, wenn das Speicherlimit bei einer der stündlichen Messungen wieder unterschritten wird, dann fände ich das eine durchaus akzeptable Lösung. Höchstens eine Stunde nach der Behebung des Problems wäre man wieder entsperrt und der Support müsste noch nicht mal eingreifen.


    Ich hatte bis vor einigen Wochen tatsächlich ein tägliches (oder besser nächtliches) Backup von 2 RS auf mein Webhosting laufen lassen. Das war keine übergroße Datenmenge (5 Snapshots pro Server, nur Benutzerdaten + Servereinstellungen und inkrementell), aber wäre da ein Fehler irgendwo in der Backup-Software (Restic) drin gewesen oder die RS hätten irgendwie verrückt gespielt, wäre mein Webhosting möglicherweise auch gesperrt worden. Mittlerweile habe ich mir beim roten H die kleinste Storage Box (1 TB) geholt. Ich dachte, ich fange mal klein an, 10 TB wären mir lieber, aber eben auch deutlich teurer. Da sichere ich jetzt auf die selbe Weise die für eine Wiederherstellung relevanten Daten von 4 Servern und habe jetzt nach mehreren Wochen schon sagenhafte 60 GB von den 1 TB der Storage Box gefüllt. Und das wächst auch nur noch, wenn ich mehr Daten auf den Servern erzeuge. Letztens der IO-Test auf 2 Servern waren gleich schon 10 GB mehr, weil ich vergesssen hatte die Dateien vor dem nächsten Backup zu löschen. Aber die sind da nach einer Woche wieder raus. Ansonsten warte ich mal gelassen ab, welche Warnmeldungen mir das rote H im Zweifelsfall schickt :) .

    Zur Hashberechnung kann man z.B. folgenden Befehl über SSH ausführen:


    cd / && find httpdocs -type f -exec md5sum {} + | tee md5sums.txt


    Damit werden von allen Dateien im httpdocs-Ordner MD5-Hashes erstellt und in der Datei md5sums.txt gespeichert sowie am Bildschirm ausgeben. (Wenn man was moderneres als MD5 haben möchte, halt einfach austauschen.)


    Zum Überprüfen auf einem anderen System gibt es die -c Option bei md5sum u.ä. Programmen. Oder alternativ kann man dort ebenfalls rekursiv die Hashes berechnen, beide Dateien sortieren (sort) und mit [color]diff vergleichen.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    2 Mal editiert, zuletzt von KB19 ()

    Gefällt mir 1 Danke 1

    Danke, teste ich Mal aus.

    Bin Mal gespannt wie lange der für die Daten dann braucht.