Debian admin here. Even Debian gets regular kernel upgrades that like a reboot afterwards. Security updates are more important than uptime. Also regular testing for clean recovery after a reboot is a must so a power outrage doesn’t bring any new surprises with it. Also test your backup restores regularly.
Novice homelaber here, is this just a case of apt update & upgrade or is there different commands for security and kernel updates? Also what’s your preferred backup/restore software? Thanks!
Your note is very interesting about the difference between the commands and how autoremove will automatically remove stuff before or after the upgrade is performed. Should it always be done after, or are there instances when running it before is more beneficial? Is there any need to do both like this:
I can’t really imagine a benefit to --autoremove except for keeping old packages a bit longer before removing them.
Eg, if you run apt --update--autoremove upgrade -y once a day you’ll keep your prior-to-currently-running-version kernel packages a day longer than if you ran autoremove immediately after each upgrade.
To make things more confusing: the new-ish apt full-upgrade command seems to remove most of what apt autoremove wants to… but not quite everything. 🤷
I am using restic and backrest on my yunohost server and I really like it! It is really set up and forget for me. Only the uploads to backblaze b2 are still triggered manually.
Also did a full recovery from the backblaze repo (downloaded locally) without problems.
Also just now heard about Zerobyte it is a backup solution based on restic and looks very good!
Yeah, people that brag about uptimes are just bragging about the fragility of their infrastructure. If designed correctly you should be able to patch and reboot infrastructure while application availability stays up.
With an uptime of greater than 5 years I’m going to be concerned about the system potentially not coming back up after a reboot/power outage, especially for physical hardware
At a bank I worked at, we had an old IBM Power server which was at that point purely used for historical data. It had multiple years of uptime and was of course a good 10+ years old. When we went to take it offline, we actually just disabled the nic on the switch so we could reduce the number of powercycles it would see in fear that it would not power on anymore. Theoretically the data on it is purely historical, backed up and not needed, but there was enough question marks on each of those fronts we just played it safe
I haven’t had a kernel update on Debian that triggered the “you should restart” message in quite some time. I was under the understanding that most newer systems now use splicing at the kernel level to not require periodic reboots.
Check for the existence of the for containing packages that recommend a reboot. Debian does not do live patching like Ubuntu does. Not least because updates to firmware are usually not applied until reboot. Also even if that were the case, regular checks for healthy reboots make sense.
Debian admin here. Even Debian gets regular kernel upgrades that like a reboot afterwards. Security updates are more important than uptime. Also regular testing for clean recovery after a reboot is a must so a power outrage doesn’t bring any new surprises with it. Also test your backup restores regularly.
Novice homelaber here, is this just a case of apt update & upgrade or is there different commands for security and kernel updates? Also what’s your preferred backup/restore software? Thanks!
Nope it’s just apt update & upgrade. Iirc apt tells you when the kernel was updated and needs a reboot as well.
Only if you installed the package
needrestartNot if you use Proxmox! One has to be careful.
I think you can do
apt upgrade --updatenow.WHAT. Does this do both sudo apt update and sudo apt upgrade?
see also –autoremove
Your note is very interesting about the difference between the commands and how autoremove will automatically remove stuff before or after the upgrade is performed. Should it always be done after, or are there instances when running it before is more beneficial? Is there any need to do both like this:
# sudo apt --update --autoremove upgrade -y && sudo apt autoremove -yI can’t really imagine a benefit to
--autoremoveexcept for keeping old packages a bit longer before removing them.Eg, if you run
apt --update --autoremove upgrade -yonce a day you’ll keep your prior-to-currently-running-version kernel packages a day longer than if you ranautoremoveimmediately after each upgrade.To make things more confusing: the new-ish
apt full-upgradecommand seems to remove most of whatapt autoremovewants to… but not quite everything. 🤷I think so. I read it a few months back, but I don’t use any apt based systems to check on.
Yup
‘apt upgrade -U’
🤯
Borg
restic (thanks @Xylight@lemdro.id )
backrest (restic with WebUI)
Also worth checking out restic. It’s more command line oriented and is generally stateless
I configured restic once, forget about it and saved my files because it was making backups since forever.
Oh, never heard about it. A quick research showed me that restic is a very viable solution. Thanks for mentioning it, I added it to my comment.
While researching, I also came across a fancy WebUI, which is mostly what non-CLI users want: backrest
I am using restic and backrest on my yunohost server and I really like it! It is really set up and forget for me. Only the uploads to backblaze b2 are still triggered manually. Also did a full recovery from the backblaze repo (downloaded locally) without problems.
Also just now heard about Zerobyte it is a backup solution based on restic and looks very good!
Thanks just installed immich and I need a quality backup system.
I appreciate the link!
Kernel updates are usually held back and need to be selected manually. E.g. apt-get install linux-image-amd64.
I prefer rsync for private backups and employ bareos in my company for all servers.
As someone running a UPS on my ubuntu server, “uptime” represents the time since the last kernel release, and not much else.
Use kexec then
New fear unlocked.
The sun was angry that day, my friend…
Yeah, people that brag about uptimes are just bragging about the fragility of their infrastructure. If designed correctly you should be able to patch and reboot infrastructure while application availability stays up.
With an uptime of greater than 5 years I’m going to be concerned about the system potentially not coming back up after a reboot/power outage, especially for physical hardware
At a bank I worked at, we had an old IBM Power server which was at that point purely used for historical data. It had multiple years of uptime and was of course a good 10+ years old. When we went to take it offline, we actually just disabled the nic on the switch so we could reduce the number of powercycles it would see in fear that it would not power on anymore. Theoretically the data on it is purely historical, backed up and not needed, but there was enough question marks on each of those fronts we just played it safe
HOT SWAP!
https://www.youtube.com/watch?v=SYRlTISvjww
What do you use for backup restores ?
The same tools.
I haven’t had a kernel update on Debian that triggered the “you should restart” message in quite some time. I was under the understanding that most newer systems now use splicing at the kernel level to not require periodic reboots.
I haven’t seen it in a while either, but also, if there is a kernel update,
uname -salways returns the old kernel until a reboot.Check for the existence of the for containing packages that recommend a reboot. Debian does not do live patching like Ubuntu does. Not least because updates to firmware are usually not applied until reboot. Also even if that were the case, regular checks for healthy reboots make sense.