Nice Way To Quickly And Completely Backup Your Sd Card


chris_c

Member
Joined
Jun 25, 2010
Messages
393
Age
56
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!
 
For a single partition card, what's wrong with a simple cp, or rsync?
 
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
 
WizardStan said:
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.
 
Last edited by a moderator:
chris_c said:
WizardStan said:
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.
 
Last edited by a moderator:
WizardStan said:
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 :)
 
Last edited by a moderator:
WizardStan said:
chris_c said:
WizardStan said:
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 :D still reckon its quicker anyhow....
 
Last edited by a moderator:
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.
 
Back
Top