incremental backups after upgrade

[oldgeek]

I have just upgraded to 20.10, and it worked well, though very slow--much quicker to do a clean install. I have backups from 20.04 on my external HD and have been making incremental backups every week. Can I continue to do the after this upgrade, or should I do a normal backup of @ and @home the first time and go for incremental backups the next time? I suspect I have to do a normal, non-incremental backup for @ as the configurations will be new--am I right? But for @home as well?

[oshunluvr]

Versions as such have no impact of your backups. In other words choose as you wish - continue as you were or start fresh. Personally, I save backup of the previous version before the upgrade just in case I have to downgrade for some reason. Much easier to restore from a snapshot than try and downgrade an install. Then I make a full backup of the upgraded install and start anew with incremental backups on that one - leaving the older version untouched. I usually wait for the new version to get long in the tooth before deleting the old one.

My snapshots are done daily and I keep a weeks worth (7). On Sunday I roll last week's snapshot into a backup and incrementally send it to the backup drive. Then clean up the backups, keeping only the latest. All of this with a cronjob script. My backup drive has Kubuntu and KDEneon 18.04 versions and 20.04 versions. The 18.04 backups are "static" - as they were before upgrading, and the 20.04 backups are updated each week.

Not important really, but I haven't installed a .10 version since 2011. I occasionally play with the regular releases in a VM, but I use my computer all day every day for work so I stick to LTS releases.

[GreyGeek]

Oshunluver, I do my backups exactly the way you do except that I did not convert my script to a cron job. Did we mind-meld and I forgot?

[oshunluvr]

Oshunluver, I do my backups exactly the way you do except that I did not convert my script to a cron job. Did we mind-meld and I forgot?

Yes. I am up to my old Vulcan tricks again!

[GreyGeek]

[oldgeek]

Thank you Oshunluvr, I shall do what you suggest. I had backed up everything before upgrading, since I had planned to downgrade if anything went wrong. I liked Groovy Gorilla in virt-manager, so I decided to try it out. I upgrade since I hadn't done it for years and was curious as to how it would be. I clean-installed to 20.04 and it took a little over an hour. Upgrading to 20.10 took four hours! Clean installs for me from now on! Really, BTRFS has simplified my life.

[jlittle]

I have just upgraded to 20.10, and it worked well, though very slow...
Upgrading to 20.10 took four hours! Clean installs for me from now on! Really, BTRFS has simplified my life.

I've heard that upgrading on btrfs is slower on btrfs, because APT does "something to do with sync" excessively, which forces some slow activity on btrfs.

I clean installed 20.04, and it took a month or so to get everything back to the state I had on 19.10. This despite having documented as well as I could every setting change, set up, and software installation since the previous full install. I'm taking the four hour upgrade next time (sometime soon I hope, if I can find the time).

[oshunluvr]

Yeah, when I upgraded my Neon install on btrfs it took a really long time. However, I don't usually upgrade so I had nothing to compare it to. It seemed excessively long to me. It didn't occur to my the file system might be partly to blame - noted.

My typical habit is to install the new release along side the current one and migrate over time. Of course, I always skip the non-LTS releases so this has been a good path.

[GreyGeek]

I always do a fresh install of a new release and then drag'n drop my files from the most recent snapshot on my archive drive, which is usually last night's snapshot. Never had a problem with anything being slow, starting at bootup and onward:

$ [B]systemd-analyze[/B]
Startup finished in 2.742s (kernel) + 3.599s (userspace) = 6.342s 
graphical.target reached after 3.585s in userspace

$ [B]systemd-analyze blame[/B]
2.172s postfix@-.service                                  
1.444s smartmontools.service                              
1.080s udisks2.service                                    
1.069s systemd-rfkill.service                             
 997ms dev-sda1.device                                    
 960ms tor@default.service                                
 897ms accounts-daemon.service                            
 766ms upower.service                                     
 688ms polkit.service                                     
 653ms cwdaemon.service                                   
 652ms man-db.service                                     
 642ms avahi-daemon.service                               
 636ms NetworkManager.service                             
 631ms systemd-resolved.service                           
 630ms apt-daily-upgrade.service                          
 617ms networkd-dispatcher.service                        
 581ms systemd-logind.service                             
 519ms grub-common.service                                
 512ms rsyslog.service

My eight core idle at 2-4%, mostly 2%.