Backing up SD card

Hi,

If I have a bootable Linux SD card for the Raspi and I want to backup it up, is it simply a case of copying all the files from that SD card to another? Is it necessary to format the new SD card as bootable first?

Ian3

it will need to be bootable

dd can do it all

[Gert van Loo]

You need a SD clone program. Indeed dd can do that. You can not use normal windows as that will only see the first partition.

I have provided instructions how make a copy on a windows system to our sale force in the past. I found you can not use on some SD interfaces particular the standard SD-slot at the front of my DELL portable does not work. I always have to use an external SD-USB adapter for this.

I suggest you read the intrusions below using a non-proprotional font.

(e.g. Courier new)

Getting an image on an SD card

==============================

BEWARE: DO THIS WRONG AND YOU CAN LOSE YOUR HARDDISK!!!

A/ download a windows utility dd.exe from http://www.chrysocome.net/dd

B/ rename it windd.exe

C/ make a copy named dd-removable.exe

(That excutable refuses to write to your harddisk as it is named dd-removable

As long as you use dd-removable.exe you can not lose your harddisk)

D/ Connect an SD card to the computer

E/ run "dd-removable --list"

Should give something like this:

rawwrite dd for windows version 0.6beta3.

Written by John Newbigin <jn@it.swin.edu.au>

This program is covered by terms of the GPL Version 2.

NT Block Device Objects

\\?\Device\Harddisk1\Partition0

link to \\?\Device\Harddisk1\DR8

Removable media other than floppy. Block size = 512

size is 4075290624 bytes

This "\\?\Device\Harddisk1\Partition0" is the part you need.

F/ To copy an image named "THEIMAGE" to the SD-card do this:

dd-removable bs=1M if=THEIMAGE of=\\?\Device\Harddisk1\Partition0

There is your disk name ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

To read an SD-card image use:

windd bs=1M if=\\?\Device\Harddisk1\Partition0 of=THE_IMAGE_READ --size

You can NOT use 'dd-removable' to read an image as that executable

refuses to access your harddisk.

Excellent instructions gert

As mentioned copying won't work.

DD is the Linux way & as Gert shows there is a Win32 version.

There is a simplier way though:

https://wiki.ubuntu.com/Win32DiskImager

which I would guess uses the http://www.chrysocome.net/dd package under the hood.

Hope you guys don't mind but I am stealing it and putting it in the wiki!

(I will add link/credit though)….

Ok done (hopefully it is ok):

http://elinux.org/RaspberryPiB.....g.2FBackup

Thanks for the information. Just one more question: can this method be used to transfer an image onto a larger SD card?

Ian3

[Gert van Loo]

Ian3 said:

Thanks for the information. Just one more question: can this method be used to transfer an image onto a larger SD card?

Ian3

No. It can only do one-on-one images and it takes a looong time especially on bigger SD cards as it copies the whole card. That is why I asked 'who can help us build SD card images' on the forum a while ago. Especially on bigger SD-cards most of the card is empty but you still copy it around.

Does the sd card need any non-file things, like flags (boot flag, system partition flag) or similar? Or does it just look for a file? Does that file need to be on a specific sector?

If the answers are no, yes, no, then it would be extremely easy to increase the size. You would just need a linux machine.

I haven't fully followed all the ins-and-outs of this thread, but I'm assuming that the simple way, in Linux, will still work (i.e., I don't need any of this Windows stuff):

dd if=/dev/sda of=/dev/sdb

(Where sda is the source SD card and sdb is the target card)

Or, you could do:

dd if=/dev/sda of=myfile.img

(switch cards)

dd if=myfile.img of=/dev/sda

OK?

Also, if the concern is that people might not have running Linux systems laying around, you could boot a live CD (or use some sort of virtual machine in which to boot the live CD).

Ian3 said:

Thanks for the information. Just one more question: can this method be used to transfer an image onto a larger SD card?

Surely it will work? After dding, run something like gparted to make the partition fill the disk?

'partclone' might be a better tool. Clonezilla uses this, although I'm not sure how it would handle the bootloader etc. I think Clonezilla uses other toold for that. But if the bootloader is simple "first ms-dos partition, type FAT16, read file named whatever" then there isn't much to do to make the booting work. I believe the main advantage is that partclone doesn't copy empty parts of the partition when reading or writing, so is faster.

As far as I understood it the processor accesses the SD card to load a binary blob, which is used to initialise the ARM core, and probably the GPU.

Once that blob has been loaded and executed the last part of that loads kernel.img from the SD card.

There is no boot sector or partition type dependencies for the boot to work, you just have to have a readable partition with the correct files in the right place, and the rest happens per that sequence.

I don't know what type of partition types the core can retrieve the binary blob from, or what type the kernel.img must be stored on. Presumably fat32 or ext2/3/4?

How do those of us who want to build from scratch get a copy of the binary blob?

I don't think using dd to write an image to a larger card will allow the partition to be resized afterwards, because it writes the original partition table (from the original card size) onto the larger card. The card image needs to be built to fit the card. At least that's my experience from imaging CF cards.

The main question is whether you take a backup of the disk or of the files on it.  The latter requires quite a lot more intelligence in the backup program, but could be considerably more efficient.

In particular, when restoring a backup it might be that only one or a few files are wrong or missing.  In that case it is much faster to read all the files to find which ones are damaged, and then replace only the ones that need to be.  This also allows potentially more intelligent handling of excess/updated files, which the user might want to keep *or* which might be causing the problem.  Damaged filesystems can also be dealt with before this step, using fsck -y.

It should be feasible to make a bootable CD for a standard PC, which eliminates the need to write anything sophisticated for Windows.  That CD could contain a standard OS image as a reference, and could therefore refer to that when taking backups (to a USB drive) for even greater efficiency.  (A checksum/permission listing file would be more efficient than simply scanning a tarball - some CD drives are slow.)

That OS image would also be used to make "blank" SD cards, starting by repartitioning and formatting, then writing the individual files (really just unpacking a tarball).

Probably the most delicate part would be simply determining which disks are the SD card and the backup medium.  We really don't want people to accidentally overwrite Windows while attempting to sort out their R-Pi.

Linux does provide some information to help guess this - there is a "rotating disk" flag, and the vendors of desktop/laptop hard disks/SSDs and SD cards are mostly a disjoint set.  We can also look for NTFS partitions (identifiable by the "file" utility with a little prodding) and assume that those are a Windows installation.  So we can usually guess well enough to avoid the main hard disk at least by default.