File shrank by 67653 bytes

[adjustman]

Hallo, ich habe ein Backupscript laufen. Das funktioniert auch soweit gut. Nur manchmal (bis jetzt nur 2x in ca. 1 Jahr) kommt per Cron diese Meldung. Ich habe schon Google und die Boardsuche bemüht, aber nix gefunden.

Code: Select all

tar: var/www/confixx/html/webalizer/web6/usage_200511.html: File shrank by 67653 bytes; padding with zeros

Ist IMHO ein Tar Fehler, aber warum? Danke im voraus.

[mattiass]

Hallo, ich habe ein Backupscript laufen. Das funktioniert auch soweit gut. Nur manchmal (bis jetzt nur 2x in ca. 1 Jahr) kommt per Cron diese Meldung. Ich habe schon Google und die Boardsuche bemüht, aber nix gefunden.

Code: Select all

tar: var/www/confixx/html/webalizer/web6/usage_200511.html: File shrank by 67653 bytes; padding with zeros

Ist IMHO ein Tar Fehler, aber warum? Danke im voraus.

Einfach mal ins Blaue: Die tatsächlich gelesene Datei ist kleiner als die zunächst ermittelte Größenangabe im Dateisystem. Ist hier möglicherweise ein Konsistenzcheck des FS nötig -- denn auf den Statistiken von 2005 wird ja nicht gerade während des Backups herumgeschrieben, oder?

[adjustman]

denn auf den Statistiken von 2005 wird ja nicht gerade während des Backups herumgeschrieben, oder?

nee, wahrscheinlich nicht. Was schlägst du vor? Ist ein aktives System, Produktivsystem

[mattiass]

denn auf den Statistiken von 2005 wird ja nicht gerade während des Backups herumgeschrieben, oder?

nee, wahrscheinlich nicht. Was schlägst du vor? Ist ein aktives System, Produktivsystem

Heute Nacht um Drei herunterfahren, Rettungssystem booten, Dateisystemcheck dürchführen. Ist dann "scheduled downtime". :-)

Und mal einen Blick in die Logs werfen: können ab und zu Blöcke nicht richtig gelesen werden? Was sagt der SMART-Status?

[adjustman]

Rettungssystem booten

hab ich leider nicht. :(

[isotopp]

Code: Select all

tar: var/www/confixx/html/webalizer/web6/usage_200511.html: File shrank by 67653 bytes; padding with zeros

Ist IMHO ein Tar Fehler, aber warum? Danke im voraus.

Dein Backup ist nicht konsistent. Die Größe der Datei hat sich verändert während tar das Backup der Datei durchgeführt hat.

Es ist wesentlich besser, ein Backup von einem Dateisystem als Snapshot zu machen, etwa mit "lvcreate -s", das Snapshot zu mounten und zu sichern, anstatt das Backup von einem Life Dateisystem zu machen. Nach dem Backup kannst Du den Snapshot dann ja wegwerfen. Das setzt jedoch eine Installation auf einem LVM-System voraus.

Dein Dateisystem ist nicht inkonsistent, nur Dein Backup ist es. Je nachdem, welche Datei da angemeckert wird, kann ein Recovery von dem Backup mehr oder weniger schwer sein.

Nachtrag: Im tar-Source findet man in src/create.c (das ist der Code, der die Option "-c" implementiert) die Meldung "%s: File shrank by %s byte; padding with zeros" in der Funktion dump_regular_file(). Die Funktion besteht aus einer großen "while (size_left > 0)"-Schleife, in der mit der Funktion safe_read() count (maximal bufsize) Bytes an Daten gelesen werden. Wenn count != bufsize ist, hat die Datei nicht die erwartete Größe und tar druckt die Meldung.

Das kann nur dann der Fall sein, wenn das Dateisystem die Größe falsch zurückgibt oder die Datei die Größe während des Backups geändert hat.

[adjustman]

Code: Select all

tar: var/www/confixx/html/webalizer/web6/usage_200511.html: File shrank by 67653 bytes; padding with zeros

oder die Datei die Größe während des Backups geändert hat.

was ja speziell bei dieser Datei sehr unwahrscheinlich ist :roll:
Und wenn also die Datei NICHT geändert wurde, warum kommt die Meldung erst "jetzt"?

[mattiass]

was ja speziell bei dieser Datei sehr unwahrscheinlich ist :roll:
Und wenn also die Datei NICHT geändert wurde, warum kommt die Meldung erst "jetzt"?

Weil das Dateisystem möglicherweise beschädigt ist!

[adjustman]

ok. Kann man denn im laufenden Betrieb einen Check machen?

[Joe User]

Das hängt vom betroffenen FS und dem Mountpoint ab und kann durchaus zum Datenverlust führen. Ich würde davon abraten...

[adjustman]

Das hängt vom betroffenen FS und dem Mountpoint ab und kann durchaus zum Datenverlust führen. Ich würde davon abraten...

und was kann ich dann tun? Beten?

[Joe User]

Ja und zusätzlich den Anbieter um Hilfe bitten ;)

[elch_mg]

zum Beispiel ;)
Hast du denn keine Möglichkeit, dir ein Rettungssystem zu basteln? Ich meine mich schwach zu entsinnen, dass man im laufenden Betrieb in ein System wechseln kann, was komplett in einer Ramdisk läuft und es so erlaubt, die /-Part auszuhängen. Dann könntest du sowohl den FS-Check machen, als auch gleich ein Rettungssystem basteln - Ich nehme jetzt einfach mal an, dass du dafür die Partitionen umbiegen musst.

[mattiass]

zum Beispiel ;)
Hast du denn keine Möglichkeit, dir ein Rettungssystem zu basteln? Ich meine mich schwach zu entsinnen, dass man im laufenden Betrieb in ein System wechseln kann, was komplett in einer Ramdisk läuft und es so erlaubt, die /-Part auszuhängen. Dann könntest du sowohl den FS-Check machen, als auch gleich ein Rettungssystem basteln - Ich nehme jetzt einfach mal an, dass du dafür die Partitionen umbiegen musst.

Ja. Man kann mit einer Busybox recht schnell ein RootFS mit SSH-Server auf die Beine stellen, das die entsprechenden Tools und einen SSH-Daemon enthält. Das Teil wird dann einfach in der menu.lst als eigenes Betriebssystem eingetragen...

Welches Dateisystem wird verwendet? Werden irgendwelche RAID-Treiber benötigt?

[Joe User]

Ungetestet:
Rescuesystem im swap anlegen, /-Partition in der fstab auf das Rescue setzen, dann "mount -o remount -a", fscheck und dann das gleiches Spiel zum Verlassen des Rescue. Sollte theoretisch funktionieren und zwei reboots sparen...

[adjustman]

Welches Dateisystem wird verwendet?

ext2

Werden irgendwelche RAID-Treiber benötigt?

nein