😂
Also for procrastination fans:

>ls -latr

Some `diff` action for the folks who like their C diffs contextful, colorful, and recursive:

`diff -burp --color`

in a home lab environment do you have a preferred method of doing so?

I’d imagine if I’m doing a regular rsync between two raid setups at separate locations I could do a review of data… but not sure that’d be the most effective use of time.

What is it they say, "an untested backup is just wishful thinking", something like that?

Anyway, if you haven't tested your backups lately, do so. That's my "jobs for the weekend" pitch to you all to plan for this weekend.

@abroad_octopus I mentioned this to another respondent but basically what I recommend is you unplug the system, disconnect it from everything. Then, try restoring whatever you backed up.

If it's a full system backup, you should try restoring it to a new machine (acting like the old one was blinked out of existence, melted in a fireball, whatever). Basically- do unto your data as a schoolhouse fire drill would do unto you.

@abroad_octopus If it's a mass of important files, you should make sure that you can access those files on a new machine - again, with the old one shut off and disconnected from the world.

The important thing is ensuring that you don't need the old machine to restore the data. Extending this to the 321 system, make sure you can get to your offsite backup, and crucially, know how much time that will take. If retrieving your backup takes a year, that's something you should know.

a sincere question that maybe could be video worthy: how?

Like, I currently am using the Backups app in Ubuntu (which is apparently just deja dup rebranded) and the only way I can think of to test it is to format my PC's SSD and try to restore it. But that seems like a REALLY RISKY way to test a backup.

So how would, say, an experienced sysadmin such as yourself test a backup without creating an actual emergency scenario?