Backing up using dd

Discussion in 'all things UNIX' started by Searching_ _ _, May 19, 2011.

Thread Status:
Not open for further replies.
  1. Searching_ _ _

    Searching_ _ _ Registered Member

    Joined:
    Jan 2, 2008
    Posts:
    1,988
    Location:
    iAnywhere
    I'm trying to make a backup using dd.

    From sda to sdb as .img
    Code:
    dd if=/dev/sda of=/dev/sdb1/disk.img
    I have trashed the target "sdb" ext3 file system in attempts.
    Could you suggest a better syntax?
     
  2. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    Yes, for the output file (of).
    Since you're backing up to an image file, you need to provide a proper path. Somewhere in your local filesystem, like /home/yourname/backups/..., or some usb drive mounted in /media, or local drive in /mnt. Not /dev.
    You would use dev to backup it up or to clone (from/to) it.

    I have no idea what your command would do btw, but it doesn't look good :)
    I'm no expert and i rarely use dd.

    Try reading this - http://wiki.linuxquestions.org/wiki/Dd
     
    Last edited: May 19, 2011
  3. Searching_ _ _

    Searching_ _ _ Registered Member

    Joined:
    Jan 2, 2008
    Posts:
    1,988
    Location:
    iAnywhere
    I found a few forensic sites that make suggestions.

    This one suggests first making a directory then mounting it.
    Code:
    mkdir usbhdd
    mount /dev/sdb1 usbhdd
    http://djlab.com/2010/08/creating-forensic-copies-and-backups-of-any-media/

    Is the mkdir creating the directory in the current user of the Live session?
    I'm working from a Live CD and concerned with running out of memory, will this affect the memory of the current live session?

    The other site, which confirms your /mnt suggestion, suggests this:
    The last step is to mount the filesystem, that will recieve the backup, in our file structure:
    Code:
    # mount /dev/hdx1 /mnt/test 
    http://www.lnx4n6.be/index.php?sec=Documentation&page=netcatdd

    The first site is missing the /mnt and the second site is missing the mkdir.
    The inconsistencies make me hesitate about which series of commands is the correct method.

    I feel a little lost, from lnx4n6.be, following step 4:
    Since I'm not doing this over a network but disk to disk,
    Code:
    # dd if=/dev/hdy conv=noerror,sync| pipebench | netcat 192.168.0.1 2000 
    combined with,
    Code:
    # netcat -l -p 2000 -w 5 | pipebench > /mnt/test/image.dd 
    to get,
    Code:
    # dd if=/dev/hdy conv=noerror,sync /mnt/test/image.dd
    Will the "sync" option be needed in a disk to disk operation?
    Are there any problems changing the tut's image.dd to disk.img?
     
  4. lotuseclat79

    lotuseclat79 Registered Member

    Joined:
    Jun 16, 2005
    Posts:
    5,097
    You might give some attention to using the blocksize parameter in the dd command as that can speed up the process, but using bs=512 (the default - I believe) is not conducive to that goal. Use something that is a large multiple of 1024 like 32KB or 64KB (numerical values, of course), or higher.

    For example, if you wanted to create a 500 MB swap file from within a mounted partition:
    # dd if=/dev/zero of=swap bs=1M count=500

    -- Tom
     
  5. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    It's creating the directory wherever you're at, the working directory. If, for example, you're at the livecd /home, then yes, i think it's creating it 'in the current user of the Live session', and all in RAM.
    To make sure where you are, type 'pwd' (print working directory).
    I don't know for sure, but i don't see any problem.
    The first site either omitted a 'cd /mnt' (if it's a local drive) or they're simply not following the usually recommended path.
    The second site omitted the mkdir.
    Note that i'm not actually reading any of the articles, just the part you mention.
    Well, i'm more than lost on that one. :)
    Maybe Mrk can help?
     
  6. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    8,698
    I'm here :) the knight in shiny spandex.

    Do you want to perform raw data copy - partition to partition without regard to filesystem structure on top of it? Or do you want the data to be meaningful in some way? Better yet, what are you trying to achieve :) ?

    I would recommend (and looking through mentioned stuff):

    Backing up data using dd not from the context of a running os.
    I'd boot from live cd, mount partition to /mnt, then dd contents underneath to backup device. Moreover, if you want to have data structure preserved, use the same inode size on source and target. Alternatively, backup the device itself to a file (see below).

    Does this help?

    Some more data on the Intertubes:
    http://www.linuxweblog.com/dd-image


    Cheers,
    Mrk
     
  7. Searching_ _ _

    Searching_ _ _ Registered Member

    Joined:
    Jan 2, 2008
    Posts:
    1,988
    Location:
    iAnywhere
    My favorite color is blue...no, green?

    I need a bit by bit copy for analysis. Been having trouble with accessing devices with a hex/disk editor, something was blocking access. dd documentation states it can make an exact copy of the entire layout, whether information is their or not, which I can then look at with the hex/disk editor.

    The drive being copied is flash media, 2gb PNY, into HDD ext3 partition as a file (.img or .dd).
    What should I expect in the copy, a fragmented non-contiguous file structure or a contiguous file structure?

    I have successfully made a copy so far, but something weird occurred in the mount procedures, the data did not become logically visible until a reboot, though console searching says it was present.

    I know that "noerror" relates to bad blocks, when the switch is used it omits any bad blocks.

    All 3 sites combine to build a more complete picture. I'd like to see these guys write instructions on how to build a peanutbutter and jelly sandwhich before they are allowed to write a Howto. :D
     
Loading...
Thread Status:
Not open for further replies.