Linux4Bene wrote: > I am in the process of moving my server to another VPS. > The goal is to keep the old VPS around and convert it to backup MX & DNS > amongst other things. I will purchase the new VPS from another company so > I can't just copy the vm file/container. > > As a start, I would do a full tar archive of the old server and start > from there. A test on a local VM worked, with some adjustments. Both use > Debian 7.8. The services on the old server that need to me moved: > - Mail: Postfix, Dovecot, Spamassassin, Clamav, Postgresql, ... > - Web: nginx, supervisord, python, php5-fpm, Postgresql, ... > - DNS: PowerDNS This is one of those hard topics. It seems easy enough. But the reality is that there are many subtle problems. It comes up for discussion every so often over the years. I don't think there has ever been a completely satisfactory canonical one true answer that solves the problem in one collection. There just isn't any perfect methods. Instead all that we can suggest is to understand everything and deal with it ad-hoc. This is exactly what you are doing. With what you have written I can tell that you are very much aware of most of the traps and pitfalls and are dealing with them as best as you can. Good job! It would be good if there were a better way to deal with this. There are many different strategies. Some people favor one strategy. Other people favor other strategies. You and I have already diverged from favored strategy. Personally I prefer to build a pristine system and then install the new services upon it. That allows me to be refreshed in everything. (On the other hand I always upgrade servers in place. I carry the upgrade history along with me. An irony of opposites for me I know.) I would use this as an opportunity to clean and clean and clean. But it is okay if you tell me you want to have the identical server, as identical as possible, moved without doing that in this step. That is fine too. > Tar command from the backup script on the old server: > EXCLUDE="--exclude=proc --exclude=sys --exclude=dev/pts --exclude=backups" > tar -czpf /backups/full.tar.gz --directory=/ $EXCLUDE / 2>&1 Since /dev is dynamic I exclude /dev from the backup too. Your new installation will already have a static copy of the minimum dev under the udev mount point. > I know I can migrate by first installing all packages, and then copying > the config and data from one server to the other. But then you need to > pick all data to be moved. It takes longer and it's more prone to error > (forgetting something). I want this server to be exactly the same as the > first one. One sideways strategy that you might consider for risk management is to untar a copy of your old system into what will become a chroot area on the new system. That will give you a reference on the new system. You can run services from there. But mainly it would give you a way to do an A-B comparison between what you had before and what you are creating new. I do that often. If something shows up being different then can go investigate the way things were and find lost and forgotten tweaks and revive them. > What I've found so far in my test: > - It's a good thing to first install all the same packages on the new > machine first. I didn't do that in my first test and Postfix wouldn't > come up because of Exim that was installed on the base version of the new > OS. Simple to solve but this wouldn't have happened if I had installed > Postfix first as Exim would have been purged. Right. They intentionally confict with each other and push each other out. It will sound obvious but postfix can't come up if it isn't installed. :-) But if you were overwriting *everything* on the system from the backup on one to the new system then after having done so then postfix would have been installed. Right? The binaries in /usr/sbin/postfix would have been copied into place and the package manager would think it had installed it in /var/lib/dpkg too. The biggest issue being any daemon that changed uids and was running would need to have been stopped before this and restarted after this. Right? This is one of the issues that makes doing it this way tricky. Not impossible. Just tricky. > Might be better to start with: > Old server: dpkg --get-selections > packages > New server: dpkg --set-selections < packages Yes. That is what that was designed for along with some other things such as the dselect-upgrade and so forth. Those will be suggested and with identical versions (Stable, OldStable) they should be able to replicate the same packages installed on each machine. There are some issues with doing it this way. You should read about 'apt-mark' and the database flag that indicates whether the package has been installed explicitly or automatically. Automatically installed packages without anything depending upon them are candidates for 'apt-get autoremove' to remove them. Explicitly installed packages are not. You can dump the previous values from the old server with: apt-mark showauto apt-mark showmanual And then use the lists to set the same values in the new server. Here is one way. I will leave you to fiddle with this further. apt-mark auto $(cat list-of-auto-packages) You can tell by comparing the results before and after: apt-get autoremove > - Extract the tar archive from the root on the new server This makes me nervous. For one /dev is a udev dynamically controlled file system and shouldn't be overwritten like this. But that is minor and easily handled by avoiding /dev. And also because the user ids of system users and groups are dependent upon the order in which they are installed. When doing a system splat from one system on top of another all of /etc/passwd, group, shadow, gshadow being overwritten with new numbers for all of the system installed accounts. Of course that is matched by completely overwriting all of the files elsewhere too. And because it won't remove files on the new server that weren't on the old server and those files will become orphaned when /var/lib/dpkg is overwritten. As long as it is a complete overwrite of *everything* then it works. But for files either extra or missing it can cause problems. That doesn't feel right. You could try tracking all of those files but that is a lot of work. You might even tell me that there aren't any of those files to worry about. But this worry is is mostly why I would install the packages okay but then only make configuration changes in /etc instead of untaring the entire system. Having said this it is something that gets done periodically and it does work. Google does upgrades across its data centers "one file at a time" using rsync. Pretty amazingly cool. And then there is Guillem Jover's older 'debtakeover' project. http://www.hadrons.org/~guillem/debian/debtakeover/README The debtakeover project replaces a foreign non-Debian system (such as Red Hat or SuSE) with a Debian system in-place while the system is running. It basically replaces the system out from under itself with the new system. It is ten years old and nothing recently done with it but I note it simply as another amazing example of this type of thing done and actually working to at least some extent. I personally tend to always arrange things so that I am keeping services alive by knowing what the system is doing in total and being able to install that list of services. Therefore I haven't had need to stress this side of things. > - Adjust /etc/hostname, /etc/hosts, /etc/network/interfaces /etc/mailname /etc/postfix/main.cf /etc/postfix/transport /etc/fstab > - Adjust PowerDNS settings on new server. If the new server is up I will > need to change the PowerDNS settings on the old server as well and set up > DNS synchronization. DNS entries at the domain registrars & reverse DNS > will need to be changed. > - Check configs of the services above for the old ip or hostname > - Run update-grub as the id of the disk has changed. The id or the UUID? This won't have changed the UUID or the disk label. However the /boot kernels may have changed. > - Reboot > > This worked well, but I wonder if there are good reasons to not do move > the server like this? > > Thanks for any info or insight I don't know how insightful any of this is but this is what I thought of when I read your posting. Good luck! Bob
Attachment:
signature.asc
Description: Digital signature