On Tue, Nov 19, 2019 at 12:31:25PM +0200, Dumitru Moldovan wrote:
On Sun, Nov 17, 2019 at 03:12:06PM -0800, Lev Lazinskiy wrote:
This makes sense, but I was curious what the recommended approach is for
a server that you cannot simply reinstall.
A humble piece of advice from a fellow system admin... Never ever build
a system that "you cannot simply reinstall." There should be at least
two ways to redo everything:
1. From scratch using documentation or preferably a modern deployment
system such as Ansible, Salt, etc.
2. From backup. This should be drilled from time to time, even
without a practical need, just to make sure things work as expected.
Yes, practice is not as simple as theory and I admit being guilty at
times of every possible mistake in not following the above. :-]
But, realistically speaking, as long as a system still functions, it
should be reproducible. Document the setup, backup its configs and
saved data, etc.
May be bad advice for your situation, but this is what I used to do
when migrating setups that were not documented or easy to redeploy:
1. Install the same OS on new hardware, in your case with a better
partitioned drive.
2. rsync everything relevant to the new machine (but make sure it
still boots afterwards and functions as expected, so amend boot
manager files, hardware-dependant configs etc.).
3. Update relevant DNS records for affected services AND set packet
redirection for services on the old machines until DNS propagation
does its thing (which is usually much longer than expected, esp.
for public services, even if you lower TTLs well in advance).
If you don't have spare hardware for the migration, I guess you could
use a spare VM until you repartition drives in your old hardware as
needed. If you don't care about service disruption, I guess you could
skip redirection.
Hope that helps!
