24 Oct, 2011, Rarva.Riendf wrote in the 2nd comment:
Unless you can find the exact same distrib/same material on another provider it is way better to document what exactly you did (and why) than to try to save a full setup that you will have a hard time to restore.
It also helps to track what you exactly need, because one day or another you will forget that you need to redirect some port for some reason you hardly ever use, and the day it breaks you have no idea why if you only apply the same setup without remembering what is in it.
Better have script recreating the setup than saving it verbatim. Most admin I have seen do that. They have a full image of the server, because they can have hardware failure, but rebuilding a server is made by script, not by applying a copied setup.
It also helps to track what you exactly need, because one day or another you will forget that you need to redirect some port for some reason you hardly ever use, and the day it breaks you have no idea why if you only apply the same setup without remembering what is in it.
Better have script recreating the setup than saving it verbatim. Most admin I have seen do that. They have a full image of the server, because they can have hardware failure, but rebuilding a server is made by script, not by applying a copied setup.
24 Oct, 2011, quixadhal wrote in the 3rd comment:
Yep, couldn't agree more.
If your VPS provider is a decent one, they can probably make one of their own VM snapshot images available to you for download periodically, but most of the time when I upgrade or migrate servers, I end up using the downtime as an opportunity to upgrade to a newer version of Debian as well. Thus, I try to keep a text file called /root/HACKLOG, which just has quick one-line notes whenever I install a new package or adjust the config of something.
Like most documentation, you won't always remember/bother to update it… but if you do, it makes rebuilding your server much smoother and faster. :)
If your VPS provider is a decent one, they can probably make one of their own VM snapshot images available to you for download periodically, but most of the time when I upgrade or migrate servers, I end up using the downtime as an opportunity to upgrade to a newer version of Debian as well. Thus, I try to keep a text file called /root/HACKLOG, which just has quick one-line notes whenever I install a new package or adjust the config of something.
Like most documentation, you won't always remember/bother to update it… but if you do, it makes rebuilding your server much smoother and faster. :)
24 Oct, 2011, Runter wrote in the 4th comment:
My experience with this is that the best way for configuration (broadly) is encapsulating it inside of your app. If at all possible you want to include manifests and environment configuration etc all at a per app basis. This turns out to be much better than trying to globally configure a server to meet the needs of your app, and then try to remember what you did later. This also includes dependancies and packages. With dependancies it's important to use some type of manifest, because if you know something works with a specific version of a library you may not want the updated version without reason. Very often newer versions of libraries aren't backwards compatible. Or introduce an error that your app catches. If you don't know which versions it's been tested for at some later date it can be a nightmare changing the deployment with different dependency versions.
Random Picks
I see a lot of options out there (rsync, external backup services, etc.) but opinions are welcome.