Re: Moving server to new server with tar
Op Sat, 06 Jun 2015 13:59:16 -0600, schreef Bob Proulx:
> 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.
Bob,
thanks for your reply and the time invested. Much appreciated.
It does indeed seem tricky unless you go the full monty and replace the
whole installation except for the special dirs like dev as you noted.
In my test, I didn't get any strange results in the end but I have
learned not to always trust what I see in IT. In the back of my mind, I
always suspect a problem popping up when the server is in production.
>> 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.
Indeed, it should be excluded as well. Good point.
> 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.
That's a really good idea. Untar in a separate directory and manage the
installation of the services from there or use it as a base for
comparison. I like it.
> 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.
The reason why postfix didn't want to start, even after untarring the
whole system was because exim was still running. After stopping exim, I
could start postfix without a hitch.
>> 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
I didn't think of the autoremove feature. Hmmm. Might have a big impact
on the server. Thanks for pointing this out.
>> - 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.
This made me nervous too, but on my test I didnt get any system weirdness
as it was a full system copy. As you said, dev should be excluded from
the archive. But because this type of install overwrites everything, I
thought it might actually work :)
> 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.
Indeed. And the users is one of the reasons why I did want to try a full
copy otherwise these subtleties could make the move harder.
Same with databases and the database users.
The fully copy means not having to worry with creating the users on the
system and database level.
> 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.
Wow I didn't know that. They rsync their servers? That's binaries and
config I suppose?
> 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.
That's impressive. It sounds a bit like a Debian borg system :)
<snip>
>> - Adjust /etc/hostname, /etc/hosts, /etc/network/interfaces
>
> /etc/mailname /etc/postfix/main.cf /etc/postfix/transport /etc/fstab
>
Indeed, those need to be checked as well.
>> - 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.
When I rebooted the system, it failed because the UUID was still the UUID
of the main disk of the old system. I didn't change it manually but I did
an upgrade-grub from a rescue session from the Debian iso. Afterwards,
the system rebooted so I assumed the UUID was corrected by running
upgrade-grub?
Bob, thanks for your thorough explanation & insight.
Regards,
Benedict
Reply to: