Beside all the helpful comments: If this is a serious problem for your business, invest in Cloudflare or other professional bot-protection. They do fingerprinting and similar stuff.
Also, if you implement your own methods, do shadow-banning of bots that you identified. These attacks will stop if the time and effort the malicious actor has to invest outweigh the benefits, so the more time and effort you let them waste, the better. A good example are unsolvable and ridiculously captchas. That is obviously a double-edged sword - you need a good way of whitelisting known good actors, so the effect of false-positives on your customers is minimized.
yes. The ADHD fulfilling dopamine rush has a consequence on your brain chemistry. I started reading books in addition to blog posts, articles, etc. and it had a positive outcome on my mood. I'm reducing my internet-dopamine time more now.
professionally printed ones, yes. However, finding a good print service has become a real hassle and most photos that I printed start to fade after 10ish years.
I did the analysis as well, calculated everything and ended up paying 500 bucks for an external service. Everything else would have cost roughly the same (with buying a good and used slide scanner and selling it afterwards) plus the countless hours for loading and unloading the scanner and retouching, etc. Just use an external service - if he doesn't trust "some online service", I found a lot of small, family-owned businesses in drivable range to go to. They're usually more expensive, but you know where to knock if something goes wrong.
First, I'd recommend thinning out - multiple terabytes sounds very extensive and can be thinned by removing duplicates and by using better compression like webp or x265, removing unnecessary raw-files, etc.
My personal backup is the usual 3-2-1: 3 backups, 2 places, 1 offline. I have one copy on my local harddrive (that I work with), one automatically synced copy via seafile on one of my dedicated servers (which also maintains a few months of history in case I accidentally delete something) and I have one external, offline harddrive at a relatives house, that I sync to every half a year or so. Since I'm paranoid, my dedicated server is backed up to an external storage every night as well via borgbackup. If you don't want to spend a few bucks a month on backblaze or another service, just use a local NAS - as long as you have one harddrive offline and external as well (in case of a ransomware attack that crypts all files).
Important: My files and backups are fully encrypted and it's imperative(!) that you backup all documentation, all config files, all settings, all cronjobs, all executables that have something to do with the backup and restoration process unencrypted with every backup - in the desaster case, nothing sucks more than trying to find the right settings again.
Case in point: I originally used a custom shell script and encoded the files with openssl. However, the default hash scheme was changed between openssl 1.0 and openssl 1.1 (or something like that) and when it came to restoring after a harddrive failure, this took me like a weekend to sort out.
As for posterity: it's up to you if you encrypt the external drive at a relative - if you're fine with a burglar having the images and you cannot be ransomed with them (e.g. due to nudes), just write what is on the harddrive clearly and you're fine.
While you're right, I'd recommend against both for the specific use-case. You just added another layer. The extra software needs to be available, maybe it's not developed anymore and won't compile on your system, maybe they changed the alphabet from which the words are generated, ...
OpenSSH private keys are armoured by default, gpg-keys can be exported and imported in an armored format - and everything else can be just printed as hex representation with whatever tool (e.g. `od -Ax <file>` or any other).
The backup part is quite easy - generate a well-known file with 1kb of data and include it in your backups. After the backup completed, validate that you can restore the well-known file and compare the content of the original and the restored. Easy to automate if you run a well-customizable backup system.
Storytime: I did not check the restoration of my backups some time ago and had a faulty harddrive, so I needed to restore the backup. Backup was also as dumb as possible - essentially a tar and encrypting it with openssl. So I reinstalled the server, tried to decrypt it - got the error, that the key was wrong. Took me a good weekend to find out, that openssl changed the default hash algorithm between openssl 1.0 and 1.1. This would not have been catched with the proposed system, but now I really pin all default options in my scripts as well.
The more complex your system grows, the more often it will fail and shoot you in the foot. I'd advise against systems like Hashicorp Vault - they just increase the complexity and while they have their merits in complex setups, you seem to be too small to be able to operate such a system.
Have an offline backup printed along with the disaster recovery checklist and documentation and put them in a safe in your company - the checklist should be dumb enough that your drunk self can use it at four in the morning, because you were the nearest employee when everything went down.
Ensure that you have stupid manual processes in place on rotation of the safe's PIN and encryption keys in general, including a sanity check if the newly generated keys actually work (e.g. if they are used for your backup storage, actually back something up and restore it). Ensure that the safe's PIN is available to at least another person and used regularly (e.g. because you store your backup tapes there).
If you feel that you need to change from this very simple system to a more complex one, ask yourself why. What does your change actually add in terms of security and what risks does it add.
In the end, you want your system available to customers and the security you add is to not only secure the data, but actually to know who can access it (the auditing part).