3

What would be the best way to go about taking a regular copy/image/whatever of a live (Ubuntu LTS Hardy) server, so that I can run it as a local test and backup environment within Parallels.

More detail:

  • I have a live web server, hosted on Ubuntu, accessible via SSH/SCP/SFTP etc.
  • I have parallels installed on my OS X development machine.

I'd like to have as exact a copy of the live machine as possible, running within Parallels for testing and as alast resort backup.

I assume the low tech way would be to install Ununtu within Parallels then take regular sftp/scp copies of the server directory structure.

However, I was wondering if there was a 'cleverer' way of doing this, such as some form of automatic Virtual Machine creation from an existing system - like ghosting.

Jon Hadley
  • 305
  • 2
  • 7
  • 20

2 Answers2

3

I don't know about an automatic VM-creation tool; I just wanted to provide some detail as to your low-tech method.

To be specific, there are two "low-tech" ways, depending on whether you can afford for the server to be offline for a little while.

  1. Take server offline, attach a backup drive, run dd over / and any other major system partitions to create exact images on the backup drive, detach backup drive, return server to service. The backup drive now contains a full image of the server at the time of backup. (This is probably not something you'd want to do every couple of weeks, but you could incrementally update such an image with rsync or similar.)

  2. Don't take server offline; instead, take a listing of all packages and versions installed on the system (eg dpkg -l > server.packages.list); install a base system in Parallels; install packages to match the listing from the server; backup the server's /etc, any other major configuration files, and any major data sources (eg /var/www) and copy them to your Parallels system.

In the absence of a virtualizing tool, it might be easier to go with option #2. The initial VM creation would take some time, but you could easily create and backup an image of that system, just before applying changes taken from the live server. Then you've got an instant fresh-install image, and the backup-from-server-then-restore-to-VM can be scripted such that it'll be fairly easy to redo from scratch (or from the backed-up fresh install) every once in a while.

In fact, you might go with #2 anyway, and look at it as an opportunity to periodically check your backup solution: if you can restore from your backups to the fresh-install image, you know your backup solution is good. If you can't, you know you've got something to work on.

quack quixote
  • 1,735
  • 1
  • 14
  • 17
  • smart idea to backup the packages list ! – Antoine Benkemoun Dec 24 '09 at 09:49
  • apparently you can also use `dpkg --get-selections > selections.list` ... and `dpkg --set-selections < selections.list` will restoe from that. a little more automagic than the `dpkg -l` solution, but it's not something i've tested heavily. – quack quixote Jan 05 '10 at 08:25
1

The way I would do it for myself is somehow in the line of answer #2 from ~quack.

I would initially install the same base system that is living on your live server in your VM (this in order to have your hardware recognised, grub working, etc...). Then i would rsync all the relevant filetree (so for example not /proc or /dev or /tmp) from the live server to the development one.

Since rsync is based on the idea that only the data that is changed is copied over, after the initial setup, it would then be rather quick to re-sync the development server with the live one.

The difficult that I can anticipate (but I am sure many more are just around the corner!) is that some configuration files might actually need to be different on the two systems (for example those containing the UUID of the devices) and it might be difficult to understand which ones and exclude them from the rsync process.

As a sidenote two observations:

  • I find that for most of my needs I do not need my development environment to match that closely my production server. And I "pair" my two system with a mixture of versioning system (code) and scripts (database).
  • If your main concern is to have an exact copy of your running system in order to have an easy way to restore it in case of backup, then you could try G4L in combination with zsync (which is a similar concept to rsync, but developed specifically for large files like partition images and cd ISO).

HTH.

mac
  • 500
  • 1
  • 5
  • 15