Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 5 of 5
  1. #1

    Backing up and restoring pi sd cards

    Just a 'Heads Up' for those like me who muddle along happily enjoying screwing things up on a rasberry pi secure in the knowledge that any damage can be rectified with a new sd card and a saved image. I always back up my sd card at monthly intervals doing something like this on my linux desktop:-

    sudo dd if=/dev/sdc of=/home/jsnell/Videos/backup.img bs=1M

    I then store the resulting backup.img files keeping the last three made. The theory is that if I screw things up badly on the pi, I can simply use Disk Image Writer from my file browser to burn the image onto a new card, insert it into the pi and I'm back in business.

    As I was about to do something probably unwise, I decided to actually burn an up-to-date replacement card before I screwed up the working one. I was somewhat puzzled (concerned, apprehensive, horrified) when Disk Image Writer refused to burn the .img on to a spare sd card, giving some message to the effect that the backup.img file was some 350 MB bigger than the size of the card I wanted it burnt to. Since they were both 32GB cards, I found this difficult to understand. Well a bit of googling re-educated me about that, it seems that manufacturing defects can result in 'bad' blocks resulting in a volume size of less than the nominal card size. More googling provided me with a work around, not particularly elegant but at least it worked.


    1.Resize the biggest partition on the current working card with Gparted reducing the size by say 500MB

    2. back up the card to backup.img using something like:-
    sudo dd if=/dev/sdc of=/home/jsnell/Videos/backup.img bs=1M

    3. Then cd to the directory the backup.img file is in, insert the new card in the usb reader and run:-

    sudo dd if=backup.img of=/dev/sdc

    NB This will take several hours (around 5 in my case) to run and will terminate with an errors message (dd: writing to '/dev/sdc': No space left on device) which can be ignored.

    I am sure the linux experts in here can provide more elegant solutions but, as I said, it worked for me. Please note I am NOT such an expert and decline to take any responsibility for unforeseen consequences! Hope this helps someone anyway

    Jerry

  2. #2
    Senior Member
    Join Date
    Apr 2008
    Location
    Paris, France
    Posts
    2,108
    Yes SD cards marketed for a certain storage size have indeed differences in actual storage. If you buy 2 SDs of the same type at the same time, probably coming from the same batch, a straight cloning can probably work, otherwise it won't.
    This is not really a problem, hard drives are not interchangeable either.

    The problem is the size of the filesystem within the SD (the image). If it takes 100% of that media and your cloning procedure ends with a short write, your clone ends up with a broken filesystem.
    The thing to do is a. not use 100% of the available space, or b. run something like "resize2fs" to shrink the filesystem before you take the image of the system.
    If you prefer, you can take an image as it is, "loop-mount" the image under a machine, and shrink the filesystem within the image.
    Then the restore procedure should work across SDs.

    If you omit the block size parameter (bs=), dd reverts to its old self and transfers records of 512 bytes. That's fine for tape cartridges and hard drives from the 80's but it is also extremely slow. bs=1M (one megabyte) should work fine on any platform and will be much faster.
    3 SB 3 • Libratone Loop, Zipp Mini • iPeng (iPhone + iPad) • LMS 7.9 (linux) with plugins: CD Player, WaveInput, Triode's BBC iPlayer by bpa • IRBlaster by Gwendesign (Felix) • Server Power Control by Gordon Harris • Smart Mix, Music Walk With Me, What Was That Tune? by Michael Herger • PowerSave by Jason Holtzapple • Song Info, Song Lyrics by Erland Isaksson • AirPlay Bridge by philippe_44 • WeatherTime by Martin Rehfeld • Auto Dim Display, SaverSwitcher, ContextMenu by Peter Watkins.

  3. #3
    Senior Member
    Join Date
    Jan 2011
    Location
    Staffordshire. UK
    Posts
    1,988
    I found this page a while ago but as yet have not had time to give it a try.

    I think I'll be doin a lot of when I do

    http://www.aoakley.com/articles/2015...-sd-images.php

    ronnie

  4. #4
    Senior Member
    Join Date
    Apr 2008
    Location
    Paris, France
    Posts
    2,108
    Quote Originally Posted by Man in a van View Post
    It's a bit verbose and outdated. losetup, finding the offset yourself...: these days, do "kpartx -a myimage" and then "mount /dev/mapper/loop0p1 /mnt" (or whichever loop mount and partition you'd like).
    At least it is not dangerous, I came across a "how-to shoot yourself in the foot" that professed reducing the partition first, and second filesystem...

    I don't like parted, IMHO it is always in a semi broken state. Things work, stop working, are back... Normally you can do with these on the command-line:
    - fdisk myimage: just to see which partitions are in there
    - kpartx -a to create the loop mounts with the right offsets
    - mount
    - resize2fs
    - umount
    - fdisk myimage, again: if you want to reduce the size of the partition whose FS you just shrinked. Optional and please don't shrink the partition too much and truncate the filesystem within it.. There is no way to "reduce" a partition. What you do is destroy it and re-create it. You'd use the same start boundary as reported by fdisk, and for the end boundary as already said don't cut it too thin.
    Tools that offer partition resizing do these 2 things: resize the FS, nuke and recreate the partition.

    Note your image file will stay the same size all along, only now it will be filled with junk or blank at the end. If you want to reduce the size of the image file itself, you can use "truncate" but then again, don't truncate that file so much that it cuts either the partition boundary or the FS within it. Safer and efficient, you can compress the image file.
    3 SB 3 • Libratone Loop, Zipp Mini • iPeng (iPhone + iPad) • LMS 7.9 (linux) with plugins: CD Player, WaveInput, Triode's BBC iPlayer by bpa • IRBlaster by Gwendesign (Felix) • Server Power Control by Gordon Harris • Smart Mix, Music Walk With Me, What Was That Tune? by Michael Herger • PowerSave by Jason Holtzapple • Song Info, Song Lyrics by Erland Isaksson • AirPlay Bridge by philippe_44 • WeatherTime by Martin Rehfeld • Auto Dim Display, SaverSwitcher, ContextMenu by Peter Watkins.

  5. #5
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    648
    Quote Originally Posted by epoch1970 View Post
    It's a bit verbose and outdated. losetup, finding the offset yourself...:
    The article links to the raspbian-shrink script, which automates the whole procedure.
    I've successfully reduced a 16GB image to 3GB (which compresses to 500MB) with it (haven't tried to restore it, but the script does some checks after truncating the image, so it should be fine)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •