you are viewing a single comment's thread
view the rest of the comments
[–] 248 points 8 months ago (8 children)

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.

  • source
  • hideshow 16 child comments
  • [–] 37 points 8 months ago (5 children)

    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!

  • source
  • parent
  • hideshow 10 child comments
  • [–] 30 points 8 months ago (3 children)

    Nope it's just apt update & upgrade. Iirc apt tells you when the kernel was updated and needs a reboot as well.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 4 points 8 months ago (1 child)

    full-upgrade probably a better pick

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 8 months ago (1 child)

    Is it? Afaik that also removes incompatible packages so if you've installed some custom stuff that might not be the best option.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 8 months ago

    You should be reading the proposed changes before pushing yes. But regardless you can get stuck upgrading if you use only "upgrade" when dependences intentionally incompatibly change by package maintainers

  • source
  • parent
  • [–] 21 points 8 months ago (3 children)

    I think you can do apt upgrade --update now.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 6 points 8 months ago* (3 children)

    WHAT. Does this do both sudo apt update and sudo apt upgrade?

  • source
  • parent
  • hideshow 6 child comments
  • [–] 5 points 8 months ago (1 child)
  • [–] 1 point 8 months ago* (1 child)

    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 -y
    
    
  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 8 months ago

    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. 🤷

  • source
  • parent
  • [–] 4 points 8 months ago* (last edited 8 months ago) (1 child)
  • [–] 2 points 8 months ago (1 child)

    Incredible that it's not written everywhere, I always wanted to use something like this without the " update && upgrade" which looks like is not working oftentimes

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 8 months ago (1 child)

    Is it really not written? I saw apt upgrade --update and knew the standard shortcut would be -u, but that didn't work so I tried -U, bingo bongo off I went.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 8 months ago

    It am quite sure in the manual, but if you just look on the interwebz tutorials every command line just writes the full shebang. So you don't look up the manual and get flabbergasted when you see this post. btw: if you are able to guess "what the standard shortcut would be", you are a wizard Harry 🥳

  • source
  • parent
  • [–] 13 points 8 months ago* (last edited 8 months ago) (2 children)
  • [–] 10 points 8 months ago (2 children)

    Also worth checking out restic. It's more command line oriented and is generally stateless

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 8 months ago (1 child)

    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

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 8 months ago* (last edited 8 months ago)

    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!

  • source
  • parent
  • [–] 6 points 8 months ago

    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.

  • source
  • parent
  • [–] 3 points 8 months ago* (last edited 8 months ago) (1 child)

    I'm not the person you asked the question of. I'm a fellow novice homelaber.

    I use Kopia to backup my data folders and Docker container data. Works really well. The project for this weekend is to set offsite backups to be uploaded to iDrive.

    When I update I use this:

    sudo apt update && \ sudo apt upgrade -y && \ sudo apt full-upgrade -y && \ flatpak update -y 2>/dev/null; \ sudo apt autoremove -y && \ sudo apt autoclean && \ sudo journalctl --vacuum-time=7d

  • source
  • parent
  • hideshow 2 child comments
  • [–] 8 points 8 months ago (1 child)

    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.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 8 months ago

    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

  • source
  • parent
  • [–] 5 points 8 months ago (2 children)

    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.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 8 months ago

    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.

  • source
  • parent