8

My company needs to setup a development server and we already have 2 production RHEL 6 servers working under a L4 switch.

One of the solutions to setup the dev server was to simple copy all files from one of the production servers and tweak it a little.

I've never done it before but it sounds similar to ghost imaging... can it be done? Is it recommended? Would it be prone to errors?

200_success
  • 4,701
  • 1
  • 24
  • 42
yhware
  • 249
  • 1
  • 3
  • 6

4 Answers4

17

Why not convert the running systems to Virtual Machines? Most hypervisors like VMware or Hyper-V have a tool to convert a running system to a virtual machine easily.

You can then work with a non-production system as you wish before doing anything on a production server.

Thanks to @WernerCD

Vmware

Hyper-V

Dave M
  • 4,494
  • 21
  • 30
  • 30
  • I'm afraid that kind of modification is out of the picture... – yhware Aug 22 '14 at 19:27
  • 6
    @dK3 I think you misunderstand. You wouldn't be modifying the production servers (unless you want to). You'd be installing a small tool on one of the production servers to let your VM solution "explore" it and create an image of it. You install the VM solution on your development box and point it at the "converted" image of your prod server. So, if you don't *already* have a development environment, this solution isn't a "change" ... – svidgen Aug 22 '14 at 19:34
  • 2
    Google `P2V` Physical to Virtual -- Vmware: https://my.vmware.com/web/vmware/evalcenter?p=converter - HyperV: http://social.technet.microsoft.com/wiki/contents/articles/9790.hyper-v-p2v-with-disk2vhd.aspx - Virtualize, backup, isolate (so if it's pointing towards a production database) and then have fun – WernerCD Aug 23 '14 at 02:57
9

Can it be done?

Definitely yes. I have copied an entire Linux server by simply packing up the files with tar and extracted them again on the target server. The only caveat I recall was having to remember to use --numeric-owner when extracting. I can't speak for other OS and other tools, but I imagine it is doable with all major operating systems.

Should it be done?

This question is a bit more complicated to answer. I won't recommend simply cloning a production system for the purpose of development. It may very well contain lots of user data as well as key material, which you do not want to have present on development systems.

But cloning your production system can be a good idea for other purposes.

The approach I would recommend for creating a clone of the production system is to restore from backup. You can avoid performance impact on the production system by restoring from a backup, and you get to test your restore procedure, which is a good thing.

It is important to keep the clone you restored from backup isolated from the rest of the world. Since it was restored from a backup of a production system, it may contain automated jobs, which will communicate with other production systems, and it will have the credentials to do so.

You could potentially cause much damage, if the clone got to communicate with real production systems.

But if you keep it isolated, it gives you opportunity to test that the restored system works as intended. Moreover such a restored system could be a useful environment for the last test of new code before it is deployed to production. This may be your only opportunity to test the code on real user data, before it is actually in a position to break the production system.

kasperd
  • 29,894
  • 16
  • 72
  • 122
  • 1
    copying a system via a backup restoration...probably the *best* because it accomplishes multiple goals... – Bart Silverstrim Aug 23 '14 at 01:49
  • 1
    I would add that mounting a development system from scratch may be a good way to check the system documentation. If it happens that mounting such a server cannot be done with the documentation at hand, you have discovered an issue which might be critical to the production system (if you ever need to migrate it, or install the system for another branch, or do disaster recovery). – SJuan76 Aug 23 '14 at 18:23
7

Copying all of the files could work. It's going to depend on the OS and what kind of copy method.

One general problem is trying to copy the system while it is running. Typically at least some of the files will be locked, and therefore won't copy correctly. Using some kind of imaging software while the system is shut down is usually safest (you mentioned Ghost which is one example)

Brett
  • 86
  • 2
  • It's RHEL6. Can it be done? – yhware Aug 22 '14 at 19:00
  • RSYNC is designed for mirroring and available on just about any system. You can use that. – Jeff Clayton Aug 22 '14 at 19:18
  • It entirely depends on the application, I'd like to point out. If your application is Websphere, for example, you can't just bring over all of the config files because they reference the server name. – mfinni Aug 22 '14 at 19:38
  • What about apache + tomcat7 combination? – yhware Aug 22 '14 at 20:20
  • 4
    What do you mean by "*locked*"? That's a fairly Windows view of things. The usual issue with copying a live FS in UNIX is that files change underneath you while they're being copied. – MadHatter Aug 23 '14 at 20:11
  • 1
    ...an issue which can be avoided with systems using LVM by using LVM snapshots to take a consistent image of the underlying block device and duplicating that, rather than running copy operations at the filesystem level. – Charles Duffy Aug 24 '14 at 17:24
6

Feasibility

Sure, it's possible, because it's not hard to "install" Linux using unconventional means. You could, for example, replicate the server using rsync over SSH.

  1. Boot the target machine into a "rescue" image, whether using a Red Hat DVD, Ubuntu live boot, Knoppix, whatever.
  2. Partition and format the target machine, and mount the filesystems under a /target.
  3. rsync all relevant filesystems over SSH (skipping /proc, /sys, swap).
  4. Fix up /target/etc/fstab, especially if the partitions are referred to by UUID.
  5. Tweak hostname and network configuration as appropriate.
  6. Install the boot loader.

Step 3 could consist of multiple rsync passes, possibly aided by LVM snapshots on the source machine, the last pass with all services on the source machine stopped to ensure data consistency.

Desirability and best practices

Just because you can doesn't mean you should. I've recommended the process above as one way to do a data center migration. However, your use case is quite different. Resorting to cloning highlights some deficiencies:

  • Virtualization would be a nice capability to have, and would make replication easy.
  • Do you have backups of your production server(s)? Why not just restore them? This would be a good test of your backup restoration procedure.
  • Do you have documentation of how to reproduce everything from scratch? Eventually, you will probably need to install from scratch, perhaps when you upgrade the operating system. This would be good validation for your documentation.
  • Better yet, do you have automation that helps you reproduce your setup? A shell script could work; a configuration management solution such as CFengine, Puppet, Chef, or Ansible would be even better.

If you blindly clone the production server, you'll lose a valuable opportunity to clarify exactly what is running on it.

Community
  • 1
200_success
  • 4,701
  • 1
  • 24
  • 42