On Thu, 2005-07-07 at 11:56 -0500, scott wrote: > Hi guys: > > I'm about to migrate a sever to a managed server facility. I've alwau=ys > used tape to backup my server, now that's not an option. I've read abut > using rsync to do backups and have several scripts to do same. I believe > rsync is a good solution. > > I am missing some important nuiances though... I would like to have > essentially a "mirror" server at my facility ( call it "master") that I can > backup to, and from, completely from the other server (call it "hosted"). > > Obviously I have to have at least different IP addresses on "master" and > "hosted", but other than that, I'd like them to be mirrors of each other. I > would like to do all my configs, setup, etc. at my leisure on "master", > where I have hands on control, then when ready, have "hosted" setup with a > basic Centos server install, then configure it to rsync to my "master" and > update the entire thing (updates and all) to my "master". > > 1. Which files tdo I need to exclude to avoid IP address and hostname > changes? /etc/sysconfig/network /etc/sysconfig/network-scripts/ifcfg-eth0 Likely also want to exclude: /etc/sysconfig/hwconf /etc/fstab /etc/mtab /etc/ssh/ /root/.ssh/ /boot/grub/grub.conf /boot/grub/device.map Will need a /etc/hosts that is compatible with both machines. I'm no doubt forgetting some others to exclude. > 2. What caveats do I need to be aware of? Are there other files such as > 'live" libraries that I cannot sync to? Doing this to a live system is VERY likely to be problematic. How about a ping-pong approach where you keep two bootable systems on the "hosted" system (on different partitions or physical disks) and update the one not being used, fix up grub and other files (see below), and reboot to the new image. Gives you the untouched installation to fall back on, but could still be a problem if boot fails and you have nobody on-site to help. > 3. The "master" server at my facility and their server may have different > hard drive architecture (i.e. IDS and SCSI drives, different processor, > etc.). As long as I use a generic Kernel (i.e. stock) that supposts the > hardware on both, this shoudl not be a problem, right? May need to run mkinitrd on the "hosted" machine if the hardware is different, edit /boot/grub/grub.conf, and possibly /etc/fstab and /etc/mtab, before booting to a new kernel. In the past, I've found the existence of /etc/mtab~ to cause problems on reboot, so watch out for cleaning up the backup file if using emacs or another editor that uses that convention. > 4. Am I missing something, is there a better way? Would work better, involve less manual fix-up, and be less error-prone to have identical hardware. I'd consider just keeping a local backup image of the "hosted" machine for disaster recovery, and perhaps use a local "slave" (as opposed to "master") system for testing updates before installing them on the "hosted" system. Could still use rsync for backups without worrying about excludes. Phil