Find the answer to your Linux question:
Results 1 to 5 of 5
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    rsync for "bare metal" backup? Will this work?

    I'm trying to explore a good backup routine that will restore my complete system "bare metal" to it's current state in case of some catastropic event. I've looked at partimage, mondorescue, and some others. However, those backup applications only work if your using the same partition scheme. I do use partimage weekly in case I ever need to restore to this machine only.

    However, looking down the road, I can see where I may buy a new laptop with a bigger HDD and would want restore my / filesystem. I've looked at two options: rsync and dump

    I like dump because it has a -L flag that utilizes a .snap directory to take a snapshot of a live filesystem BEFORE collecting data so that any open files wouldn't (or unlikely) be corrupted.

    BUT, I also really like rsync, however I am REAL unsure if the following scenario would work on a live filesystem. What is everyones thoughts on the following..

    Currently on a 110 GB, Dell Laptop running Ubuntu 8.04 LTS. About 9 GB of data on the system.

    In the / directory I create a file called exclude and in this file list files/directories I do not want backed up.


    Then, I create the directory /usr/backup and from the / of the filesystem in single user/root shell run:

    rsync --delete-after -avz --exclude-from=exclude / /usr/backup/

    Theoretically, / and /usr/backup/ should be a mirror correct?

    Lets say for a year, I did this nightly, then creative a tar archive of this data on a USB external. If I then decide to buy a new laptop, install Ubuntu, mount the external and un-tar to /usr/backup and run:

    rsync --delete-after -avz --exclude-from=exclude /usr/backup/ /

    would this completely restore my system without any hitches? I realize I would have to reconfigure certain hardware like video, sound and others regardless.

    So, thoughts?


  2. #2
    Linux Guru bigtomrodney's Avatar
    Join Date
    Nov 2004
    The problem with this is that you won't be copying your MBR and your bootloader will be sensitive to its location on the hard drive. You might actually be closer with Partimage It'll work fine for restoring to a disk that's in use for the same Linux installation though. You'd be best doing this in an offline mode, maybe using a livecd or similar environment.

    If you want a straight clone of your disk, partitions ignored you can use dd to do the job. If you restore to a different bigger disk later you can restore the dd image and use gparted to enlarge your partitions. The downside is you'd need to do this offline too. If you had a second disk perhaps; an external USB drive, or an available network share.

    The syntax would be something like
    dd if=/dev/sda of=/path/to/image.dd_bs512 bs=512
    Note that I've used bs512 as part of the filename to remind you should you ever need to restore it. You could then restore by reversing the command
    dd if=/path/to/image.dd_bs512 bs=512 of=/dev/sda
    To gzip the image as part of the command you can pipe it -
    dd if=/dev/sda bs=512| gzip –cf | dd of=image.dd_bs512.gz bs=512

  3. #3
    Hrm, ok, that makes sense! I didn't think about using gparted after. I'm assuming your code below backs up the MBR only? My / is /dev/sda1

    So I would boot into a Live CD, and do two things:

    # To clone the HDD
    dd if=/dev/sda1 | gzip -cf | dd of=/my/external/USB/image # which will be image.gz

    # To get the MBR
    dd if=/dev/sda bs=512 | gzip –cf | dd of=/my/external/USB/mbr # which will be mbr.gz

    Then, if I buy a laptop with 200 GB of extra data, restore image.gz and mbr.gz normally then use gparted to extend the partition?


  4. $spacer_open
  5. #4
    Linux Guru bigtomrodney's Avatar
    Join Date
    Nov 2004
    Quote Originally Posted by ubunut View Post
    Hrm, ok, that makes sense! I didn't think about using gparted after. I'm assuming your code below backs up the MBR only? My / is /dev/sda1
    Good reasoning, but not quite

    It actually backs up the entire disk in its raw form, ignoring partition schemes. I'm talking about a raw bit-for-bit copy of the data, so you can't ask for better than that. All of your MBR, filesystem tables etc are there in one stream.

    Now if you only wanted the MBR copied just add the argument count=1. You have already specified a bytesize of 512 which is the size of your MBR, and count 1 means it only copies the first 512. So MBR backed up You'll often come across a quick disk blank of
    dd if=/dev/urandom of=/dev/sda bs=512 count=1
    What this does is write jibberish over the MBR so that the disk can't be read. It doesn't actually wipe the data though. Sometimes you will see this with /dev/null to write zeroes instead.

  6. #5
    pure genius! I'm going to try that now... course I guess I could just backup the MBR with dd, partimage for sda1 and if I ever get a new computer with a larger HD, wipe the HD, restore my old mbr, reboot, restore the sda1 image, then use gparted to resize sda1.

    Nonetheless, your a genius, thanks


Posting Permissions

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