The idea that a reinstall means starting all over from the beginning isn't true. It is just like moving houses. We get a new roof, new plumbing, new electrical lines, new fixtures that work just a little different, and carpeting. Then we bring in our furniture, nick-knacks, drapes, shower curtains, valences, and boxes a few minutes later. It is our HOME, just improved, faster, more efficient, perhaps with a nicer garage.
I'm with CatKiller. Start with a fresh install. This solves so many issues. With a basic fresh install, we get all sorts of HW optimizations and the ability to change the underlying hardware, GPU, storage setup, file systems, for the better.
After the minimal fresh install with the DE I wanted, I'd copy/restore from backups, most of my personal data, personal settings, basically my HOME. Actually, I'd restore all the HOME directories for every userid. That includes root in /root/. Then I'd restore the system settings, configurations, data. This the stuff that servers need, themes for desktops, whatever DBMSes, websites, stuff that is server specific, but not userid specific.
There is one problem with this method. It requires that we know which config files in /etc/ and /lib/ need to be restored to the new system. We cannot blindly restore them all, since that will break things the installed setup for the new machine. If you use rsync in a --dry-run mode, finding a list of different files could be a good first step. Next, you could use diff to compare those files. Hopefully, you'll remember the files you've changed over the years. For example, I use an HTTPS-DNS-proxy. This isn't part of the default installs, so everything related to that tool in /etc/ is new.
Don't forget any crontab files from the old install. I dump those for each account using crontab -l as part of my backup process. If you keep all the cron stuff in /etc/, then you'll have that. I keep my crontabs in /var/spool/cron/ and dump the files into /root/backups/ ... which is where I keep lots of the system information needed for recovery that isn't stored in /etc/.
Do you use virtual machines? Where are those stored? With libvirt, the default location is /var/lib/libvirt/ for the storage and /etc/libvirt/ for the VM settings. But I use LVM for the block storage of my VMs. That means the storage from them isn't mounted on the host machine - it is just an LV for each guest VM. Let's assume you have an excellent way to backup VM storage, so it is only the XML VM virtual hardware config that needs handling. I treat VMs like physical machines and back them up using the process I've outlined here. The VMs recovery process requires a fresh install of an Ubuntu Server, then I restore configs, data, and programs. Most of my servers don't have any local user accounts, so the /home/ backup is pretty tiny when compared to a desktop. Tiny:
Code:
$ du -sh /home/
621M /home/
I wouldn't restore ANY media files, yet. That's for after everything else. I keep media files outside /home/ ... so it doesn't get mixed in with files that change all the time, daily. Having a HUGE home is something I avoid. Makes versioned backups much easier and more efficient. Anyways,
Now we have a nearly ready system. IME, the install is about 15 min. The HOME directory and system stuff another 15 minutes. We're 30 min into the process.
Only 1 thing remains. Programs. We haven't installed any yet. There are 2 sorts in my world. Custom build, outside APT and packages inside APT. My backups include /usr/local/ and a list of all manually installed APT packages.
Code:
# Daily dump of current packages to $HOME/backup
`$aptmark showmanual | tee /root/backups/apt-mark.manual`;
######[ to restore pkgs ]#######
### sudo apt-mark manual $(cat apt-mark.manual)
### sudo apt-get -u dselect-upgrade
Those commands will capture the manually installed APT packages into a file. The command below it will reload those using the file and install them. Be certain each config and data files for the programs/packages have already been placed correctly, with the correct permissions first. This step takes about 15 minutes, tops.
So, in 45 minutes, we have a newly installed system, all our settings, data, configs, with all our programs back. All that is missing are huge media files which could take hours, days, weeks, to reload. But when we reboot and login using our account, it "feels" just like our old box, but faster.
I've restored systems using this method about once a year the last 9 yrs. Got a new laptop earlier this year - it worked well. Thankfully, that restore wasn't due to a failed disk or corrupted settings or failed server upgrade. I've had those previously too. Trying to restore an email server with the entire company waiting after a failed version upgrade isn't exactly fun.
Unfortunately, as with most things, the more you practice, the better you get at this stuff. The first time I attempted it, I found some critical information was missing. I worked the problem and after about 5 attempts, finally have everything necessary for a clean restore AND many extra pieces of data that are helpful for failures we don't always consider. Because my backups are done using a script, that script gets a little better every time I find sometime new that would be helpful. The last improvement was in August.
BTW, boot-repair hasn't worked too well with UEFI setups. You can manually reinstall grub, then update grub, if you like. Just be certain to keep the connected disks to a minimal number when doing that.
Adv Reply
Originally Posted by yancek
Bookmarks