4 ms·
Considering that this can be installed to a VM, an image of which is backed up, what is not automated about this solution? Maintenance: can't the distro packag
by nsomaru 13y ago
Considering that this can be installed to a VM, an image of which is backed up, what is not automated about this solution?
Maintenance: can't the distro package manager take care of that for me?
Sorry for the ignorance in my stance, but I came across this article because I'm looking to move away from Google infrastructure to hosting my own stuff, and this seemed like a great piece :)
- Goladus 13y agoVM Images not very portable, and have essentially no built-in documentation. They're also large if you're not working from a snapshot system. Basically, if the exactly prescribed restore procedure fails, a sysadmin is stuck with a virtual black box of bytes and will have to divine out what sort of configuration mismatch there might be between the image and the new host. Different block devices? Different network devices? Wrong CPU architecture? Wrong virtualdisk format? Some other magic of some sort? It can be awhile before you even get the machine up and running, to say nothing about running services. In contrast, a scripted install starts with a running, networked machine and if any point in the install procedure fails, you'll know what point it failed will have a detailed error message explaining why. You can read the script to see what it's trying to do and may be able to either correct the script for the new environment or correct the environment for the script. You can make steady progress towards restoration while if the VM restoration fails, you just keep slamming your head into the brick wall until it gives way. It's true in many situations that restoring a virtual machine snapshot is much faster and easier than a rebuild and data-restore. My experience is that it's great when it works, but a nightmare when it doesn't.