1
Warum ist die Dateigröße eines tar-Archivs größer als sein Inhalt?
Eine Frage zu find und tar an unsere Linux-Cracks
Ich habe soeben ein inkrementelles Backup eines Verzeichnisses eines Windows-Clients auf einen SLES 11-Server per find und tar gemacht. Als Ergebnis bekomme ich ein ca. 615 MB großes tar-Archiv, doch wenn ich in das Archiv hineinschaue, enthält es nur eine einzige Datei, die nur rund 9,061 Byte groß ist.
Das Backup-Script zum Nachvollziehen:
Configuration
BACKUPFILE1="/<rechnername>/Thunderbird" # zu sicherndes Verzeichnis
BACKUPFILE2="/<rechnername>/Bat"
REMOTE="192.168.1.10" # Rechner auf den gesichert wird
REMOTEDIR1="/media/disk-1/BACKUP/home_backup/home/<rechnername>/Thunderbird" # Backup-Verzeichnis auf Remote-Rechner
REMOTEDIR2="/media/disk-1/BACKUP/home_backup/home/<rechnername>/Bat"
AGE="-7"
SUBJECT="Backup_fehlgeschlagen!" # im Subject kein Leerzeichen!
ERROR="./error.txt" # Text, der im Error-Fall versandt wird
MAILTO="./backup.mail" # Mailadressen, die im Error-Fall Mail erhalten
DATE=`/bin/date +%Y%m%d` # Datum im Format YearMonthDay
HOST=`/bin/hostname`
TAR=/bin/tar
FIND=/usr/bin/find
TAROPTIONS="c --exclude-from=/home/<meins>/backupscript/excludes.txt"
CAT=/bin/cat
GZIP=/usr/bin/gzip
MAIL=/usr/bin/mail
REMOTEFILE="incremental_<rechnername>".$DATE."tgz" # Dateiname der Backup-Datei
CHECK_REMOTE=`ping -c1 $REMOTE | grep packet | awk '{print $4}'` # gibt 1 (online) oder 0 (offline) zurueck
mkdir /<rechnername>
mkdir /<rechnername>/Thunderbird
mkdir /<rechnername>/Bat
mount -t cifs <rechnername>/Thunderbird /<rechnername>/Thunderbird -o username=<user>,password=<pass>
mount -t cifs<rechnername>/Bat /<rechnername>/Bat -o username=<user>,password=<pass>
if [ $CHECK_REMOTE == 1 ]; then
$FIND $BACKUPFILE1 -mtime $AGE -type f -exec tar -c -X /home/<meins>/backupscript/excludes.txt {} \; | $GZIP | cat > $REMOTEDIR1$REMOTEFILE
$FIND $BACKUPFILE2 -mtime $AGE -type f -exec tar -c -X /home/<meins>/backupscript/excludes.txt {} \; | $GZIP | cat > $REMOTEDIR2$REMOTEFILE
[...]
(the names have been changed to protect the innocent)
So ist diese Backuplösung jedenfalls aus nachvollziehbaren Gründen keine Option.
Wenn mich jemand über die Hintergründe dieser wundersamen Dateivergrößerung aufklären könnte, wäre ich sehr dankbar.
Fehlende relevante Informationen liefere ich bei Bedarf natürlich nach.
Vielen Dank im Voraus!
Das Backup-Script zum Nachvollziehen:
Configuration
BACKUPFILE1="/<rechnername>/Thunderbird" # zu sicherndes Verzeichnis
BACKUPFILE2="/<rechnername>/Bat"
REMOTE="192.168.1.10" # Rechner auf den gesichert wird
REMOTEDIR1="/media/disk-1/BACKUP/home_backup/home/<rechnername>/Thunderbird" # Backup-Verzeichnis auf Remote-Rechner
REMOTEDIR2="/media/disk-1/BACKUP/home_backup/home/<rechnername>/Bat"
AGE="-7"
SUBJECT="Backup_fehlgeschlagen!" # im Subject kein Leerzeichen!
ERROR="./error.txt" # Text, der im Error-Fall versandt wird
MAILTO="./backup.mail" # Mailadressen, die im Error-Fall Mail erhalten
DATE=`/bin/date +%Y%m%d` # Datum im Format YearMonthDay
HOST=`/bin/hostname`
TAR=/bin/tar
FIND=/usr/bin/find
TAROPTIONS="c --exclude-from=/home/<meins>/backupscript/excludes.txt"
CAT=/bin/cat
GZIP=/usr/bin/gzip
MAIL=/usr/bin/mail
REMOTEFILE="incremental_<rechnername>".$DATE."tgz" # Dateiname der Backup-Datei
CHECK_REMOTE=`ping -c1 $REMOTE | grep packet | awk '{print $4}'` # gibt 1 (online) oder 0 (offline) zurueck
mkdir /<rechnername>
mkdir /<rechnername>/Thunderbird
mkdir /<rechnername>/Bat
mount -t cifs <rechnername>/Thunderbird /<rechnername>/Thunderbird -o username=<user>,password=<pass>
mount -t cifs<rechnername>/Bat /<rechnername>/Bat -o username=<user>,password=<pass>
if [ $CHECK_REMOTE == 1 ]; then
$FIND $BACKUPFILE1 -mtime $AGE -type f -exec tar -c -X /home/<meins>/backupscript/excludes.txt {} \; | $GZIP | cat > $REMOTEDIR1$REMOTEFILE
$FIND $BACKUPFILE2 -mtime $AGE -type f -exec tar -c -X /home/<meins>/backupscript/excludes.txt {} \; | $GZIP | cat > $REMOTEDIR2$REMOTEFILE
[...]
(the names have been changed to protect the innocent)
So ist diese Backuplösung jedenfalls aus nachvollziehbaren Gründen keine Option.
Wenn mich jemand über die Hintergründe dieser wundersamen Dateivergrößerung aufklären könnte, wäre ich sehr dankbar.
Fehlende relevante Informationen liefere ich bei Bedarf natürlich nach.
Vielen Dank im Voraus!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 152008
Url: https://administrator.de/contentid/152008
Printed on: April 25, 2024 at 02:04 o'clock
1 Comment
Nabend,
was mir als erstes auffällt: du erstellst für jede datei die du findest, ein neues tar archive ( -exec foo \; rennt das für jedes gefundene file durch, -exec foo + macht das mit einem mal für alle gefundenen). könnte das eventuell schon das problem sein?
probier das doch am beste mal so:
das einzige problem könnte dann allerding sein, wenn er sehr viele dateien findet (ka wo die grenze genau liegt, wahrscheinlich ein paar tausend), dann bricht tar leider ab und man müsste das archiv recursiv aufbauen.
mfg
was mir als erstes auffällt: du erstellst für jede datei die du findest, ein neues tar archive ( -exec foo \; rennt das für jedes gefundene file durch, -exec foo + macht das mit einem mal für alle gefundenen). könnte das eventuell schon das problem sein?
probier das doch am beste mal so:
$FIND $BACKUPFILE1 -mtime $AGE -type f -exec tar -X /home/<meins>/backupscript/excludes.txt -czf $REMOTEDIR1$REMOTEFILE +
das einzige problem könnte dann allerding sein, wenn er sehr viele dateien findet (ka wo die grenze genau liegt, wahrscheinlich ein paar tausend), dann bricht tar leider ab und man müsste das archiv recursiv aufbauen.
mfg
