0

I'm in the following situation:

I need to "clone" the disks (sda, sdb) of a running CentOS VM over SSH (i did this step by following this guide) and deploy them on something like VirtualBox.

I tried, but unfortunately after getting the raw images of sda and sdb and after having converted them to VHD with VBoxManage I added them to a new VM and I get "No bootable media" when I start it.

Do you have any suggestion?

I tried an automated recovery with a CentOS live cd, but it doesn't find any recoverable disk; I also tried to get any information with fdisk, but unfortunately it seems like it's unable to read any partition...

Thank you very much for your help!

Community
  • 1
Brutus
  • 101
  • 1

1 Answers1

0

If you have network access from your live CD boot, you should be able to do something like this:

  1. get a root shell in the Live CD running on the VirtualBox VM

  2. partition and format the virtual disks however you want. If LVM tools are on the Live CD you can even use LVM.

  3. run mkdir -p /target

  4. mount your intended rootfs on /target, make directories for any mount-points (e.g. /target/home, /target/var, etc) and mount the appropriate partitions.

  5. cd /target

  6. rsync -a --exclude proc/** --exclude sys/** --exclude dev/** root@remoteVM:/ ./

(that rsync command might need to be fine-tuned. run with --dry-run option until it's just right)

  1. for i in dev dev/pts proc sys ; do mount -o bind /$i /target/$i ; done

  2. chroot /target.

  3. edit /etc/fstab and /etc/default/grub as needed to suit the new system.

  4. update-grub

  5. exit

  6. unmount /target and everything under it (including the bind mounts above)

  7. reboot.

Alternatively, instead of rsync, you can use tar to backup the remote VM's filesystems and put the tar.gz files somewhere you can get at from the Live CD. exclude /proc, /dev, and /sys directories from the backup.

Note: if you're running mysql or postgres or anything that writes to db files or other non- plain-text files, you'll want to shut down those services before the rsync. running a database backup to dump all dbs to text is also a good idea.

writes to plain text files (e.g. log files) during the rsync aren't so risky, if you don't mind losing any log entries that occurred after you ran the rsync....at least there won't be any file corruption possible.

systemd's journal is binary. so if you're running systemd you'll need to shutdown journald to avoid corruption. I have no idea if that's even possible without shutting down the system.

cas
  • 78,579