Hi John! On 20.02.2016 12:34, John Thornton wrote: > I see two ways to clone a HD on the web one using dd and one using tar. > > Boot from the live cd. Mount your destination media to (say) /mnt. > > dd if=/dev/sd whatever of=/mnt/mybackup.ddimg > > In this case what do they mean by mount?
It depends on what you want to achieve. If you want to clone a HD in a two-step process going over an image file, then this approach is fine. "Mounting" the destination media in this case just means to make it accessible in the same way as you would do outside the LiveCD environment, i.e. by doing it manually using something like # mount /dev/sdX /mnt or by clicking the drive in the file browser. If you plug in a removable disk, it might also be mounted automatically. On recent versions of Ubuntu, the standard mounting location is /media/username/drivename The directory /mnt is not special at all, it is just kind of a convention to use it as a mount point for some media. But you could just as easily create a folder on your desktop and mount the drive there. A few words to dd: You may get somewhat faster operation by letting it working with larger chunks of data. I usually use something like # dd if=src of=dest bs=1M so that it reads and writes 1MiB blocks instead of the default (probably 4kiB). If you know for sure that your source HD only contains data up to some address, you can avoid creating an image padded with a lot of unused data by limiting the amount of data to copy: # dd if=src of=dest bs=1M count=4000 This will copy 4000*1M=4GB of data and stop then. If you want to keep the image around, it may also be a good idea to compress it on-the-fly. This can be done by omitting the of=dest part, in which case dd will output the data to stdout, from where it can be piped through gzip (or another stream compression utility). But I'd need to look up the required flags for gzip first. > > Mount the source to /mnt, mount the destination to /home (say) > > tar cvfpz /home/mybackup.tar.gz /mnt > > does this tar create a copy of the whole disk? Maybe. While dd operates on the raw disk file (e.g. /dev/sda, you usually do NOT want /dev/sda1), tar takes all the files in the source filesystem and puts them in an archive. This may save some space and makes it easier to browse through the files, but it requires that you partition and format a new disk before copying the archive back onto it. So, depending on the use-case, I'd suggest one of those variants: - If you want to create an exact clone of a drive and can connect both the source and destination drive to your computer at the same time, then use dd without compression and directly operating on the device files of the two drives. I.e. # dd if=/dev/sda of=/dev/sdb bs=1M Make *really, really* sure that you do not mess up if and of, as dd otherwise will happily overwrite your source drive! - If you want to create a backup image of an entire disk for later copying to a fresh drive, use dd, maybe with the count flag and/or with compression and store the output in a regular file somewhere convenient. - If you want to create a backup of only one file system and want to get easy access to the individual files, use the tar approach. Good luck! Cheers, Philipp
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
