Nice Way To Quickly And Completely Backup Your Sd Card

[chris_c]

my initial kneejerk reaction to backing up my boot SD card was to use dd - obviously when backing up an OS image you have device nodes and all sorts of other considerations...

A quick trip to wolfram alpha confirmed that at even at theoretical speeds this would take a looooong time!

obviously you don't want to be copying blank sectors !

enter partclone (http://partclone.org/) which intelligently copies only used sectors

I only compiled ext* support however it compiled cleanly using only libs from the official ubuntu repo.

In a real use scenario it backed up my 8gb class 6 SD card with only 2.4GB used in a little under 10 minutes from a usb sd card reader - nice - job done!

 

[WizardStan]

For a single partition card, what's wrong with a simple cp, or rsync?

 

[skeezix]

I think he's implying a non-FAT fiesystem, containing symlinks and holey-files and random whatzits.

I tend to use cpio or cp-with-the-right-options or tar-with-right-options (cpi over network is retty win , but never heard of partclone; will take a look.

PartClone sounds like something our nub company needs

jeff

 

[chris_c]

For a single partition card, what's wrong with a simple cp, or rsync?

to quote myself

obviously when backing up an OS image you have device nodes and all sorts of other considerations...

I *boot* from the sd so I wanted the disk structure as well as the files etc, in addition walking a directory structure and copying file at a time probably also takes longer than just bulk copying used sectors.

 

[WizardStan]

For a single partition card, what's wrong with a simple cp, or rsync?

to quote myself

obviously when backing up an OS image you have device nodes and all sorts of other considerations...

Shouldn't device nodes be recreated at boot? Perhaps I am misunderstanding something.
Installing Angstrom to the BeagleBoard requires nothing more than untarring the rootfs to your prepared SD card and all devices are automatically created. Don't see why the Pandora would act any differently. You should simply be able to backup everything but /dev and when you restore the backup let the system do its thing.

 

[sebt3]

Shouldn't device nodes be recreated at boot? Perhaps I am misunderstanding something.
Installing Angstrom to the BeagleBoard requires nothing more than untarring the rootfs to your prepared SD card and all devices are automatically created. Don't see why the Pandora would act any differently. You should simply be able to backup everything but /dev and when you restore the backup let the system do its thing.

as /dev is mounted as tmpfs, I think you're right

 

[chris_c]

For a single partition card, what's wrong with a simple cp, or rsync?

to quote myself

obviously when backing up an OS image you have device nodes and all sorts of other considerations...

Shouldn't device nodes be recreated at boot? Perhaps I am misunderstanding something.
Installing Angstrom to the BeagleBoard requires nothing more than untarring the rootfs to your prepared SD card and all devices are automatically created. Don't see why the Pandora would act any differently. You should simply be able to backup everything but /dev and when you restore the backup let the system do its thing.

so i'm paranoid still reckon its quicker anyhow....

 

[pder]

For this kind of backup I really like the tool FSArchiver

Copied from the homepage:

• Support for basic file attributes (permissions, owner, ...)
• Support for multiple file-systems per archive
• Support for extended attributes (they are used by SELinux)
• Support the basic file-system attributes (label, uuid, block-size) for all linux file-systems
• Support for ntfs filesystems (ability to create flexible clones of windows partitions)
• Checksumming of everything which is written in the archive (headers, data blocks, whole files)
• Ability to restore an archive which is corrupt (it will just skip the current file)
• Multi-threaded lzo, gzip, bzip2, lzma compression: if you have a dual-core / quad-core it will use all the power of your cpu
• Lzma compression (slow but very efficient algorithm) to make your archive smaller.
• Support for splitting large archives into several files with a fixed maximum size
• Encryption of the archive using a password. Based on blowfish from libcrypto from openssl.