Can RHEL6 servers be "copied"?
Solution 1:
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)
Solution 2:
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
Solution 3:
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.
Solution 4:
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.
- Boot the target machine into a "rescue" image, whether using a Red Hat DVD, Ubuntu live boot, Knoppix, whatever.
- Partition and format the target machine, and mount the filesystems under a
/target. - rsync all relevant filesystems over SSH (skipping
/proc,/sys, swap). - Fix up
/target/etc/fstab, especially if the partitions are referred to by UUID. - Tweak hostname and network configuration as appropriate.
- 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.