Ik heb een externe harde schijf van Iomega, zo'n klein plat ding in metalliek grijs. 320GB (of 298GiB) in binnenzakformaat. Ik gebruik die momenteel om backups op te zetten, en mijn downloads (zoals Ubuntu ISO's) staan daar ook op.

Standaard komt zo'n ding in FAT32 partitionering. Op zich is dat niet zo slecht, want dan zijn die schijfjes te gebruiken op zowel Linux, Windows als Mac (vermoed ik toch, ik ken niets van Mac). Alleen ben ik onlangs op een vervelende beperking gestoten. Ik had een backup gemaakt van een usb-stick van 8GB, en zelfs gecomprimeerd met bz2 was dat nog altijd rond de 6GB. Dat is dus een probleem voor FAT32, want die kan geen bestanden aan groter dan 2GB (4GB met 64KB clusters, maar dat wordt niet algemeen ondersteund).

Ik keek dus uit naar een ander filesystem om grotere bestanden te kunnen gebruiken. Mijn vereisten:

• Ondersteuning voor grote bestanden (>4GB)
• Read/write ondersteuning in zowel Linux als Windows, voor die enkele keren dat ik de harde schijf aansluit op een Windows-pc. Dat moet niet per sé native maar het moet wel gemakkelijk te installeren zijn.
• Crashbestendig: voor wanneer ik zo lomp ben om de usb-kabel uit te trekken voor alle gegevens goed en wel op schijf staan. Dus liefst een soort journalling filesystem, zodat ik geen half uur moet wachten op een schijfcontrole.

Als ik de mogelijke kandidaten overloop, dan geeft mij dat het volgende resultaat:

Ik ga de harde schijf in hoofdzaak met Linux gebruiken, dus NTFS lijkt me dan minder geschikt. coLinux, dwz het draaien van een Linux kernel onder Windows, klinkt als een interessant idee. Maar in een artikel op PolishLinux las ik daarover het volgende:

In short, we install coLinux on a windows machine, assure access to disk partions, and export all the mounted file systems using Samba.

Okeee... dus een volledige Linuxkernel, én ook nog eens Samba? Nee dank u, dat klinkt me een beetje als overkill in de oren. Ik zoek iets dat ik snel kan installeren op een machine die ik toevallig bezoek. Er staat dan ook niet voor niets op het einde van de pagina:

This solution does not provide an outstanding performance

Dan blijft er eigenlijk alleen nog ext3 over, met een van de filesystem drivers Ext2fsd of Ext2IFS. In het verleden heb ik altijd Ext2IFS gebruikt voor zo'n situaties, maar de recentste versie is van 27/10/2008, en ik heb niet de indruk dat er nog verder aan ontwikkeld wordt. Het is ook geen Free Software (free as in speech) maar Freeware (free as in beer). Met andere woorden het is verboden om Ext2IFS aan te passen of te verbeteren...
Ext2fsd daarentegen lijkt me nog een actief project: versie 0.48 is van 1 augustus 2009, én het is wel Free Software.
Nog een verschil tussen Ext2IFS en Ext2fsd: Ext2IFS gaat ext3 partities mounten als ext2, dus zonder journal. Ext2fsd kijkt wel naar het ext3 journal. In principe kan een ext4 partitie ook gemount worden als die aangemaakt is zonder extents, maar wat is dan nog het voordeel van een ext4 partitie als je geen extents hebt? Dan kan je beter ext3 pakken...

Mijn keuze valt dus op Ext2fsd. Daarna volgde het concrete inrichten van de harde schijf. Er stond al voor 160GB aan data op dus ik ben als volgt te werk gegaan:

1. Grote bestanden wissen zodat ik ruim onder de 150GB zat. Vooral iso's van Linux distro's kwamen in aanmerking, want die kan ik gemakkelijk opnieuw downloaden.
2. Met gparted de eerste (en enige) partitie verkleinen naar 160GB.
3. Een nieuwe ext3 partitie van 160GB maken.
4. De twee partities mounten en van de FAT32-partitie naar de ext3-partitie kopiëren met
   

   sudo mkdir /mnt/fat
   sudo mkdir /mnt/ext
   sudo mount /dev/sdg1 /mnt/fat
   sudo mount /dev/sdg2 /mnt/ext
   sudo rsync -av /mnt/fat/ /mnt/ext/
   sudo chown -R amedee:amedee /mnt/ext           # alle bestanden hadden root als owner
   chmod -R 664 /mnt/ext                          # alle bestanden hadden de executable bit op FAT32
   find /mnt/ext/ -type d -exec chmod a+x {} \;   # alle directories executable bit geven zodat browsing mogelijk is.
   sudo umount /mnt/fat
   sudo umount /mnt/ext

5. Met gparted de FAT32-partitie formatteren. Die moet eerst leeg gemaakt worden, anders lukt het verkleinen niet.
6. De FAT32-partitie verkleinen naar de kleinst mogelijke grootte. Gparted maakt daar automatisch 94,10MiB van, en FAT32 wordt omgezet naar FAT16.
7. De ext3 partitie vergroten zodat die de volledige vrije ruimte gebruikt (298GiB).
8. Ext2Fsd downloaden en op de FAT-partitie zetten. Zo moet ik niet meer doen in Windows dan Ext2Fsd-0.48.exe (997,4KB) installeren.

$ sudo aptitude install backup2l

• http://www.debianhelp.co.uk/backup2l.htm (Engels)
• http://wiki.hetzner.de/index.php/Backup2l (Duits)

Het is trouwens via de tweede link dat ik backup2l heb leren kennen, van toen mijn server gehost was bij Hetzner. Ik gebruik ook de hotcopy-scripts die ze daar geven.

Backup2l voorziet zelf in een aantal courante backupformaten (tar.gz, tar.bz2,...), en het is ook mogelijk om zelf een eigen backupformaat te maken. Een nieuwe backupdriver bestaat uit een bash functie genaamd "DRIVER_drivernaam" die -test, -suffix, -create, -toc, en -extract implementeert.
Ik heb een backupdriver gemaakt die gebruik maakt van lzip, gebaseerd op het LZMA-compressiealgoritme. Dit comprimeert beter dan gzip of bzip2, maar gebruikt wel meer geheugen en is een beetje trager.
De driver moet toegevoegd worden onderaan in /etc/backup2l.conf, en dan moeten zowel CREATE_DRIVER als USER_DRIVER_LIST aangepast worden naar "DRIVER_MY_TAR_LZ".

DRIVER_MY_TAR_LZ ()
{
    case $1 in
        -test)
            require_tools tar lzip
            echo "ok"
            ;;
        -suffix)
            echo "tar.lz"
            ;;
        -create)        # Arguments: $2 = BID, $3 = archive file name, $4 = file list file
            tar -c -T $4 --no-recursion | lzip --best -c > $3 2>&1 \
                | grep -v 'tar: Removing leading .* from .*'
            ;;
        -toc)           # Arguments: $2 = BID, $3 = archive file name
            lzip -d $3 -c | tar t | sed 's#^#/#'
            ;;
        -extract)       # Arguments: $2 = BID, $3 = archive file name, $4 = file list file
            lzip -d $3 -c | tar -x --same-permission --same-owner -T $4 2>&1
            ;;
    esac
}

$ sudo aptitude install lzip

Eerst de USB-stick opvullen met een file vol nullen:

time dd if=/dev/zero of=/media/USB_2G/delete bs=1M
dd: schrijven van 'delete': Geen ruimte meer over op apparaat
1890+0 records in
1889+0 records uit
1981267968 bytes (2,0 GB) gekopieerd, 1121,06 s, 1,8 MB/s
 
real    18m41.067s
user    0m0.020s
sys     0m8.357s

Dan deze file weer wissen:

rm /media/USB_2G/delete

USB-stick unmounten:

umount /dev/sde1

Stick dumpen met dd en gzip:

time dd if=/dev/sde | gzip -c9 > USB_2G_ext2.gz
3941375+0 records in
3941375+0 records uit
2017984000 bytes (2,0 GB) gekopieerd, 198,682 s, 10,2 MB/s
 
real    3m18.687s
user    0m37.058s
sys     0m32.902s

De grootte van de backup valt echt héél goed mee!

ls -hl USB_2G_ext2.gz
-rw-r--r-- 1 amedee users 2,7M feb  7 15:40 USB_2G_ext2.gz

Achteraf de backup weer restoren:

time gunzip -c USB_2G_ext2.gz | dd of=/dev/sde
3941375+0 records in
3941375+0 records uit
2017984000 bytes (2,0 GB) gekopieerd, 461,316 s, 4,4 MB/s
 
real    7m41.322s
user    0m16.009s
sys     0m25.070s