Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a 5TB volume (non-bootable) on a Windows Server 2008 box. I need to copy it to another server over the network. Because the volume has 30 million files, filesystem copy tools like robocopy will take forever; I need a block-level copy. The source volume has to stay online during the copy -- so booting to Linux is not an option.

Acronis has to go from old volume -> image -> new volume.

What will let me go old volume -> new volume, without the image step in the middle?

share|improve this question
    
Do you require windows to be up and running while doing block-level copy? –  Manwe May 18 '12 at 13:49
    
Yes; just updated the question to say so. –  Jesse May 18 '12 at 14:01
1  
Do you have a full backup of the volume? If yes, you can restore from the backup to the new location and then sync only differences with robocopy –  Danilo Brambilla May 18 '12 at 14:11
    
No, this is a one-time move. –  Jesse May 18 '12 at 14:56

4 Answers 4

up vote 2 down vote accepted

You can use Richcopy or another multithreaded copy program and set your number of threads (in Richcopy: File Copy setting) to at least 8 or 16, and set the directory search to 4 or 8. We've used this method many times to copy millions of small files.

share|improve this answer
    
I ended up using robocopy with the /mt:16 switch. It was reasonably quick (about 18 hours) over a gigabit crossover. –  Jesse Jun 26 '12 at 12:40

You could boot a Linux disc on both machines and use dd over secure shell, that'll give you a disk copy as long as the disk drives match. If they're not the same drives, you may have some issues with the new system. Sometimes they can be fixed with Testdisk and/or Windows repair afterwards.

You do have to be really careful to pay attention to the parameters you pass (so you don't overwrite your "good" server volume). As long as you're careful the worst you will do is lose the time it takes to copy the volume over the network to see if this will work.

share|improve this answer
    
Thanks -- but I should have mentioned that I can't take the source box offline. I'll edit the question... –  Jesse May 18 '12 at 14:00
    
Depending on how full the volume is, doing a file based copy might be faster than using dd as with dd you will always read/write 5 TB, even when only 1 KB is used. –  SvW May 18 '12 at 14:01
    
@svenw is correct, it will copy the whole drive as it is. The only way it would be faster is if the file copy overhead would be very large. If you use dd piped through a compressor and then decompressed on the other side, depending on how full the volume is, it might speed things up. The whole thing is moot if you can't take it offline, though. –  Bart Silverstrim May 18 '12 at 14:26

If you use rsync or something similar (should work on Windows), the initial transfer might take some time, but you can really quickly update changed files after the first complete transfer. This is my preferred method of moving large volumes of data from one system to another.

share|improve this answer
    
Use windows rsync and I'd suggest that split your copy to smaller branches of the whole. The more you have files the more rsync will eat memory (with some options) something like this should work: rsync -vPax --numeric-ids --delete --inplace SRCDIR user@targetHost:/dir/ –  Manwe May 18 '12 at 14:20
    
Filesystem-based copy on this kind of volume takes several days; block-level copying seems to be the only reasonably "quick" approach. The benefits of rsync are lost here, because it's a one-time migration. –  Jesse May 18 '12 at 17:15

See Bart Silverstrim answer for general idea and risks. Here's the tools you need WHEN you can shutdown windows machines.

  1. Boot both systems with systemrescue cd
  2. Add root password to target machine with passwd and check that ssh is running /etc/init.d/ssh start or similar
  3. Make sure that the device/partition sizes match or target is larger.
  4. On source machine:

    dd_rescue /dev/SOURCE_PARTITION – | ssh root@targetIP ‘dd of=/dev/TARGET_PARTITION’

    # or using sparse option might work.

    dd_rescue -a /dev/SOURCE_PARTITION – | ssh root@targetIP ‘dd of=/dev/TARGET_PARTITION’

  5. Afterwards run some chkdisk on the new partition

  6. If you don't have any resizing tools ntfsresize is included in the systemrescuecd

And here are some links to examples how to accomplish it. Requires some linux device

download systemrescuecd http://www.sysresccd.org/Download

ntfsclone example (local) http://edoceo.com/exemplar/ntfsclone-transfer-windows

dd_rescue over ssh http://www.huanix.com/2009/04/11/data-recovery-using-dd_rescue-over-ssh/

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.