2

I have an Ubuntu 10.04 LTS server running production and I'd like to create a development and staging server. One option is to install everything the way it's installed on production, but this will take a lot of time to make it an exact mirror of production. Is there a way to "clone" the entire OS while it's running? I'd like to create the dev and staging server in VMWare.

Thanks!

Improve this question
2
  • You're not actually running a live production system on VMware Workstation, are you?
    – MikeyB
    May 4, 2012 at 12:15
  • 1
    If you truly have only partial backups and everything running on VMware Workstation, I wish you lots of luck!
    – Janne Pikkarainen
    May 4, 2012 at 12:50

5 Answers 5

Reset to default
7

Yes, use VMWare's Converter tool.

Improve this answer
4

Restore your backup into a fresh VM.

You do have a backup, don't you?

Improve this answer
3
  • yes, but only of the data, databases and configurations. As it relies on varnish, nginx, php-fpm, django, mysql etc, I thought it would be a better idea to clone the system.
    – FLX
    May 4, 2012 at 10:01
  • 2
    Then you don't have a backup, you have a bunch of data that might, with a whole pile of effort, might be used to restore service.
    – womble ♦
    May 4, 2012 at 11:18
  • 1
    Then why don't you add the rest of our system to the backup? This will not only allow you to clone your system, but you'll also learn what to do in an emergency.
    – Oliver
    May 4, 2012 at 11:22
0

Its possible to cold clone (ie boot off a CD, P2V converter tool), such as http://www.vmadmin.co.uk/index.php/resources/38-converter. The vmware support forums are full of useful advise for such activities. I dont know of any 'hot' cloning tools, I would be interested to hear if you find one.

Improve this answer
0

There's any number of options -- you can rsync the filesystem, dd the underlying block device over the network with netcat, or take a snapshot of the system at the vmware level and duplicate that somewhere else.

However, all of these scenarios suffer from the same basic flaw: it's one-shot deal. Once you've made the clone, you can't automatically update it to take into account changes in production (well, in theory, the rsync method can be used, but it's finicky and very error prone). This is why you need to use configuration management, like Puppet, Chef, or cfengine. These systems allow you to define the exact state you want a system to be in, and the tools will take care of the configuration. You can then specify "build all these systems the same way", and when you change the master configuration, all the machines will be updated to match the new setup. Building new machines is then also a breeze, if you need to scale up, deploy a second infrastructure in another location, or whatever else takes your fancy.

Improve this answer
0

For Linux systems, setting up a dock VM with a basic Linux installation, mounting the VMDK of the prepared empty target VM into the dock, formatting it there, quiescing the source system (read: shut the database down!), rsyncing (use --numeric-id and --exclude /proc/* and /sys/* , use -c if anything could be wrong about the clocks), then chrooting into the target filesystem, making changes required, and reinstalling the boot loader (hint: kill /dev/.udev while in chroot, then populate /dev with MAKEDEV generic), works very fine. grub-legacy would be the preferred boot loader to use (if target fs is ext3, format with -I 128 or things will break horribly! Also, junk device.map always..). If fixing a boot loader from inside chroot sounds far out of your comfort zone, better read up on that topic or leave it be ;)

Further updating of the environment can then be done with partial rsyncs and mysqldumps (acquaint yourself with the --dry-run option to rsync... --exclude is FINICKY)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .