https://github.com/valvesoftware/steam-for-linux/issues/3671
Featuring probably the most unflappable human in the history of time as a bug reporter. One day I hope to have the fortitude this man does.
https://github.com/valvesoftware/steam-for-linux/issues/3671
Featuring probably the most unflappable human in the history of time as a bug reporter. One day I hope to have the fortitude this man does.
One of my professors used to say that he should be able to destroy your laptop, buy you an equivalent new one, and you should be up and running again within a few hours. Hard drives fail all the time and computers get lost/damaged/stolen. Losing your home directory on a computer should be expected, and definitely not the end of the world.
I've been using actual raid5 (via adaptec raid card) for years and very recently had one of my trusty 5TB HGST drives fail (after 3+ yrs of uptime).
Fortunately the rebuild worked, but there are so many horror stories of raid5 rebuilds NOT working it has me contemplating going back to simple mirroring.
If you are going to use hardware raid, please do make sure you have a spare raid controller, same firmware, same model. If not, you will be SOL when your controller dies.
RAID5 these days (with our very large disks) is basically asking for trouble - the odds of a second disk failing during the reconstruction are very high. But I guess you already know that!
Now I use a more sophisticated RAID10 setup and really appreciate the way failed and replaced drives automatically rebuild themselves without my dumb interaction.
I would also mention it's probably a good idea to use something like ZFS rather than a hardware RAID card. In general, free software RAID is better audited and you don't need specific hardware for the recovery process. But also, ZFS has proper checksumming, so you won't have to worry about all sorts of silent corruption (which RAID blissfully ignores -- most implementations will just recompute the parity in case of a mismatch, which is the wrong thing to do (1-1/n) of the time).
Was hoping to utilize ZFS in 20.04... but the whole SNAP issue has me sticking with my current version.
Perhaps it's time to find a dummies guide to setting up ZFS on 18.04 LTS.
As an IT Exec (retired)... this was a lesson learned long ago. For my own/home systems I use rclone [i] (in conj w raid5) for the most critical files.
You can say 'robust' but there are limits of what I think one can reasonably expect from a user. That they had backups at all is not necessarily the norm.
If you want to guard against rogue software (or clumsy fingers in the terminal), you'll probably need to have remote backups. It sounds like copies on the cloud saved this user, and it's not unrealistic to suggest users backup to the cloud (I think many already do with OneDrive/iCloud/Dropbox). If you're a Linux user who likes to tinker, you can set up a Raspberry Pi with a hard drive attached and use restic over SFTP (or any of the other numerous choices).
That is fair. I was commenting from the perspective of what is rather than what should be. Alongside making software as safe as possible, we should also be encouraging and expecting people to do this.
By old files, that can mean any snapshot schedule you choose to set up (daily, weekly, monthly, quarterly ...).
Not sure if rsync can do local encryption these days? So I guess 'for the paranoid' (as Tarsnap's tagline is), Tarsnap with write-only keys might be better.
No one can delete the files afterwards, not even root, without removing the attribute first
It worked well with Mercurial, which is also append only. So I could commit as usually to my Mercurial repository, but it could not be deleted.
Ironically, I stopped doing that, because it messed my backups up. When running the backups as root, some tools would add the flag to the backuped files, but then later backups as non-root could not replace the file with new versions.
What do you use for that?
Secondly, treat all machines as cattle. No customization, unless done programmatically or repeated easily, and absolutely essential.
In practice, I have a tiny Dir in a Resilio share from which I bootstrap. It contains some cfg files/dies, a bashrc, passwords and share keys, some written notes for customizations that are not possible or unreliably so to automate. In my notes you will find for instance a package list for fresh installs, notes on which Firefox extensions to install, how to configure certain software that have only a GUI to reliably do so (and I test such instructions before I consider the tool ready for use), a zip of my thunderbird profile, and so on.
I started this way of thinking when my dad accidentally formatted my drive in 2000, and it has been bullet proof since. When I use new software, I do not consider it usable before I made a note or cfg backup in my 'bootstrap' share. I do not rely on my memory and I do not rely on a particular machine for anything, and it costs barely any effort other than being disciplined in never customizing a machine without recording and testing how to repeat that someday. If that is too much work? Then I will not use that software, apparently its not worth it.
[1] https://syncthing.net/ [2] https://restic.net/ [3] https://nixos.org/
rm -rf "$STEAMROOT/"*
Yes. I have bookmarked this issue as a reminder to always read every single shell script before execution. set -Eeuo pipefail