"split" an StdOut

Yohoo!

Ich versuche das folgende moelgichst effektiv hinzubekommen:

-Binaeres Einlesen eines Mediums
-Aufteilung in gleich grosse Teile
-md5 Feststellung und Notieren derselben in einer Datei
-Schreiben des jeweiligen Teiles nur, wenn sich die md5sum von der frueher geschriebenen Datei unterscheidet

Anfangs wollte ich das mit dd, tee und split machen. split hat jedoch den Nachteil, dass man es weder pausieren kann noch die Ausgabe auf StdOut geht.

Zweite Idee ist jetzt, einfach eine for Schleife anzulegen und dann dd mit dem berechneten skip- Parameter aufzurufen. Dann bekomme ich in jeder Schleifenrunde via dd auf den StdOut eine Datei, die ich dann mittels tee and md5sum und eine temporaere Datei weitergeben kann. Stimmt die md5 ueberein, wird die temporaere Datei wieder geloescht und der naechste Durchgang gestartet.
Dummerweise startet dd aber bei jedem Durchlauf von vorne. D.h liest die komplette Quelle ein und schreibt dann erst ab Block "skip" in den Output. Das bringt Geschwindigkeitsmaessig nicht wirklich viel....weiterer Nachteil ist, dass ich die Blockgroesse des Mediums vorher feststellen muss, um die richtige Anzahl an Schliefendurchgaengen zu nehmen...

Ach ja, Verbesserungen lohnen sich tatsaechlich, Quellmedium ist ca. 500GB gross!

Also, Ziel ist es, aus >500GB Blockdevice (sonst wuerde rsync gehen) mehrere (viele) Dateien mit ca. 1GB zu machen, die aber nur dann geschrieben werden sollen, wenn sie sich geaendert haben.

Jemand eine Idee?

Werde zwischenzeitlich mal mit dem Offset Parameter des loop devices spielen, das koennte gehen...

Nachdem Ihr ja alle wohl schon pennt habe ich es alleine gebastelt.

Das Skript liest jeweils 512MB aus dem Source Device, erstellt dabei die md5 und vergleicht die md5 mit der md5 der bisherig gespeicherten Datei.
Ist sie gleich, wird wieder geloescht. Ist sie verschieden, wird aktuelle Blockdatei komprimiert auf dem Zieldevice gespeichert und die md5 auch kopiert.
Dadurch wird die Datei nur einmal vom physikalischen Device gelesen. Der Rest passiert im Speicher (Ramdisk /dev/shm) Und die Zieldatei muss auch nicht gelesen werden, nur deren md5.
Der grosse vorteil ist, dass das Skript exakt linear skaliert (von der Kompression mal abgesehen). A
NAchteil ist, dass es IMMER das ganze Device liest um festzustellen, ob sich was geaendert hat.

So ,das Teil laeuft jetzt ueber Nacht. Und das mache ich auch

#!/bin/bash


SRC=/dev/sdb1
DST=/srv/backuppc
TMP_FILE=/dev/shm/tmp
DST_FILE=$DST/backuppc.gz.iso
service backuppc stop
#umount /var/lib/BackupPC
mount /srv && exit
if [ ! -e /srv/backuppc ] ; then mkdir /srv/backuppc; fi
rm -fr /dev/shm/*
sync
rm -f $DST/backuppc.log


i=0
loop=`losetup -f`


bs=$[64*1024] # blocksize 64k
fs=$[1024*1024*512] # filesize 512M
count=$[$fs/$bs] # block count per file 
devlen=`df | grep $SRC| awk '{print $2}'` # #of 1k blocks
devlen=$[$devlen*1024] # #of bytes
devbsblocks=$[$devlen/$bs] # #of 64k blocks
# In case device does not perfectly fit into 64 blocks
if [ $[$devbsblocks*$bs] -ne $devlen ] ; then devbsblocks=$[$devbsblocks+1] ; fi


files=$[$devbsblocks/$count] # #of blocks per dest file
if [ $[$files*$count] -ne $devbsblocks ] ; then files=$[$files+1] ; fi


echo $bs $fs $count $devlen $devbsblocks $files
while [ $i -le $files ] ; do
        losetup -o $[$i*$count*$bs] $loop $SRC
        dd if=$loop bs=$bs count=$count | tee $TMP_FILE.$i | md5sum > $TMP_FILE.$i.md5
        losetup -d $loop
        if [ -e $DST_FILE.$i.md5 ] ; then
                echo "diff $DST_FILE.$i.md5 $TMP_FILE.$i.md5"
                diff $DST_FILE.$i.md5 $TMP_FILE.$i.md5
                if [ $? -ne 0 ] ; then
                        echo "$i is different" >> $DST/backuppc.log
                        cat $TMP_FILE.$i | gzip -2 >  $DST_FILE.$i && rm -f $TMP_FILES.$i
                        mv $TMP_FILE.$i.md5 $DST_FILE.$i.md5
                else
                        rm -f $TMP_FILE.$i $TMP_FILE.$i.md5
                fi
        else
                cat $TMP_FILE.$i | gzip -2 >  $DST_FILE.$i && rm -f $TMP_FILES.$i
                mv $TMP_FILE.$i.md5 $DST_FILE.$i.md5
        fi
 
        i=$[$i+1]
done
umount /srv
service backuppc stop

Zitat

Originally posted by HFlor
'dd' hat doch die Option 'skip' um ab einer bestimmten Position zu lesen.

Eben nicht. Ich meine, ja es hat diese Option. Aber es "liest" doch alles von Anfang ein. Oder tut zumindest so.
D.h. es liest immer ueber die geskippten Bytes drueber. Will ich also z.B. nur die letzten 2GB lesen, liest dd mir trotzdem auch die vorhergehenden 498GB ein.

Werd's aber nochmal testen, war ja spaet gestern

Ich brauche das Skript, um ein Image Backup meiner Backuppartition zu ziehen und diese dann nach "remote" zu kopieren.
Da das Image massenweise Hardlinks enthaelt, ist jedes Dateibasierte Tool (wie z.B. rsync) vollkommen ueberfordert und braucht alleine fuer das Abgleichen der Hardlinks Tage.
Aber jedesmal das ganze Image zu transferieren, uebersteigt die Kapazietaet meiner Internetanbindung. Also Blockweise und jeweils nur die geaenderten Daten.

Zitat

Originally posted by tag
Spricht eigentlich etwas gegen dump/restore?

Ja, funktioniert nicht.
Weiss nicht mehr warum, habe es getestet, hat entweder ewig gebraucht oder hat grosse inkrementelle Sicherungen geschrieben, obwohl auf der Platte nichts geaendert wurde...
ehrlich, ich habe so ziemlich alle Optionen durch. Ausser ZFS, aber das ist mir noch zu experimentell.

An eine NamedPipe hatte ich auch gedacht- bleibt aber die Frage, wie und wo ich dann die Aufteilung in die gewuenschte Groesse mach und das den darauf aufbauenden Tools mitteile.

Irgendwie weiss ich jetzt nicht, wo ich die Named Pipe sinnvoll einbinden koennte.

Yohoo!

nochmal eine Ergaenzung, die mir gerade aufgefallen ist.

gzip erstellt IMMER verschiedene Dateiinhalte, wenn es mehrmals aufgerufen wird!
D.h. rsync kann damit nicht wirklich sinnvoll umgehen.

Macht doch mal das Folgende:

cd /tmp
cat /etc/fstab | gzip > fstab.1
cat /etc/fstab | gzip > fstab.2
md5sum fstab*

Na, faellt was auf?
Jo, genau. Die beiden komprimierten Dateien haben unterschiedliche md5sum, obwohl sie aus der gleichen Quelldatei stammen....was soll das?

Nimmt man bzip2 statt gzip, sind die Zieldateien gleich. Aber bzip2 ist soooo lahm.

Ach ja, ihr koennt die unterschiedlichen Dateien ja auch gerne wieder entpacken. Dann sind sie wieder gleich...waere ja noch schoener.

Bringt da gzip noch einen Random Wert mit rein oder was? Kann man das abstellen?

Zitat

Originally posted by tag
"gzip -n" sollte helfen.

Jo, stimmt. Danke!