Re: [Clonezilla-live] Using CZ with Logocal Volumes
A partition and disk imaging/cloning program
Brought to you by:
steven_shiau
From: Steven S. <st...@nc...> - 2010-04-17 03:53:23
|
Hi Johnny, If you have ssh, nfs, or Samba server, you can save the image on that server, and the space does not require to be 320GB, Clonezilla will only save the used blocks, and it will compress too. E.g. if the only space on the disk is about 100 GB, and the save image might be 30 GB. "Device to device" clone is not really the same as "device -> image -> device", since after you save the device as the image, you can remove the original, source disk, replace it with destination disk. Then the same LVM won't coexist at the same time. Steven. Johnny Stork wrote: > Unfortunately I dont have a spare 320gb on a single drive anywhere to > place the image. But if its an identical image, how could this make a > difference? Would this file image simply be the same image reproduced > on the second drive? > > I believe the issue has something to do with the physical drive going > from /dev/hdb to /dev/hda on the copy/target, and/or having UID's for > the drive being different. > > Thsi seems to make sense but I dont know how to address it. > > Thanks again for all your help :) > > On 4/16/2010 8:19 PM, Steven Shiau wrote: >> Hi Johnny, >> Maybe this helps. As I mentioned, if you did that via "device to >> device' option, maybe you can try to do "device-image" option. >> http://clonezilla.org/clonezilla-live/doc/fine-print.php?path=./01_Save_disk_image/06-dev-img.doc#06-dev-img.doc >> >> >> Steven. >> >> Johnny Stork wrote: >>> Thanks guys, still no luck and I guess I have to give up at this point. >>> >>> Unless there are any more suggestions? >>> >>> >>> Since the new drive is actuall physically seen as /dev/sda (the >>> original/source drive in the old RAID was seen as /dev/sdb), could >>> this be the problem and fixed with an edit to a lvm config file >>> somewhere? Or maybe they need new UID's? >>> >>> >>> >>> >>> >>> >>> I then disconnected the original source drives and booted from the >>> cloned drive alone in the system. Once again it kernel panicked and >>> could not find "VolGroup00" >>> >>> I then rebooted the CZ disk and went to the shell, and ran the >>> following: >>> >>> >>> pvscan: >>> >>> PV /dev/sda2 VG VolGroup 00 lvm2 [297.91 GiB / 0 free] >>> Total:1 [297.91 GiB] / in use:1 [297.91 GiB] / in no VG: 0 [0 ] >>> >>> vgscan: >>> >>> Found Volume Group "VolGroup00" using metadata type lvm2 >>> >>> lvscan >>> >>> >>> ACTIVE 'dev'VolGroup00/LogVol00' [20.00 Gib] inherit >>> ACTIVE 'dev'VolGroup00/LogVol02' [233.91 Gib] inherit >>> ACTIVE 'dev'VolGroup00/LogVol03' [20.00 Gib] inherit >>> ACTIVE 'dev'VolGroup00/LogVol01' [20.00 Gib] inherit >>> ACTIVE 'dev'VolGroup00/LogVol04' [4.00 Gib] inherit >>> >>> On 4/16/2010 8:02 PM, Steven Shiau wrote: >>>> Kevin W. Wall wrote: >>>>> Steven Shiau wrote: >>>>> >>>>>> BTW, for LVM, disk to disk is really done by dd in Clonezilla, so >>>>>> it's >>>>>> very inefficient... >>>>>> >>>>> What are you using for the block size for dd? If there's a way for >>>>> you to >>>>> figure out the hard drives cache size, that might be the most >>>>> efficient. >>>>> Or separate ibs& obs parameters if using different hard drives >>>>> with differing >>>>> cache sizes. In the old days, the conventional wisdom was to use >>>>> a block size >>>>> that corresponded to the block size of the file systems, but if >>>>> you are >>>>> doing raw disk I/O with modern drives that have huge on-board >>>>> caches, that >>>>> probably doesn't make sense. I'd think something like 8MB or even >>>>> 16MB would >>>>> be worth trying. Have you experimented with different sizes for bs >>>>> / ibs / obs? >>>>> >>>>> -kevin >>>>> >>>> Kevin, >>>> Thanks for sharing this. However, I was wrong... Now it's done by >>>> partclone.dd. >>>> >>>> Steven. >>>> >>> >>> >> > > -- Steven Shiau <steven _at_ nchc org tw> <steven _at_ stevenshiau org> National Center for High-performance Computing, Taiwan. http://www.nchc.org.tw Public Key Server PGP Key ID: 1024D/9762755A Fingerprint: A2A1 08B7 C22C 3D06 34DB F4BC 08B3 E3D7 9762 755A |