The only time I spent outside of the video was to deploy to Vercel. I made a bunch of speedups in the video, but didn't cut anything. The total time was about 2 hours.
I mentioned it in the post, but there was definitely some hand holding towards the end, where I don't think a non-programmer would have succeeded
Specifying the second 0 implies portions of one cent. Like if I said something costs 10USD, the one dollar bill is implied to exist even if it isn't used (same with 10.00 implying the existence of a penny)
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.
The anecdata of my random Walgreen photos seem to be holding up pretty well in the living room and hallway environment that they live in. We have some done from their "photo copy" machines from 20 years ago. Mind, I don't have master originals to do a side by side comparison, but using the Mark 1 Eyeball, they look fine. They're doing much better than my 50 year old polaroid.
While I can print photos, it's typically far easier and cheaper to have Walgreens do it.
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.
Having to archive environments and toolchains along with backups is unpleasant.
What is the plan: when decryption fails (and before you identified that it's a versioning issue with openssl, in your case) you'd reinstall an old linux to a random computer and work from there? How many config files and settings are even involved in your backup process and how can you be sure you haven't missed anything?
I hope there are dependency-free solutions for this - a winzip-encrypted .zip file that asks for a password should work everywhere even in the future?
> 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.
For the most part, just using an unusual filesystem e.g. ZFS will foil the vast, vast majority of attempts to read the data from a drive stolen from a home burglary (e.g. where the data was not the target).
Yeah, obscurity seems to help in the real world. The Presidential motorcade has a bunch of identical limos so attackers don't know which one the President is in. They, of course, have armor too. But the decoys add to the security, even if it's "by obscurity".
The content gets stolen either way.
You would save the money on window repair at the cost of losing a small deterrent (maybe a thief would refrain from making noise)
The source for most movie rips today is Bluray, which is already an encoded medium. Yet Bluray remux's are not the common distribution format.
Yea you are technically correct, but if the distance from the original is just a handful of encodes, good luck noticing any lower quality that's not simply due to poor encoding settings. And when a proper encode can be a 10th the size with hardly any drop in quality, in a video file you might view <12 more times in your life, does it really matter.
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).
Great answer, thank you. I agree with your point about testing the restore process, right now I'm trying to think of a way to automate it.
As a side note: for example we had some backups that are probably useless, because they are way too small. Catching this would mean more manual regular checks, or some automated rules, at which point it becomes quickly more complex again.
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.
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).
z-base-32 isn't going to magically disappear off the face of the earth. Anyway, here's a 32-byte secret key as hex. Still easier to type in than to drive to a data center. GPG is just horribly verbose, and the old school RSA keys are huge in comparison.
It's a 50-line CLI I wrote (just like `entropy` on the other line). It's just a simple interface for https://gitlab.com/NebulousLabs/entropy-mnemonics which is one of the many different "encode binary as words" things out there. It's the idea that matters more.
For a PKI, you can also afford relatively more complexity with respect to the root CA key if you use intermediate CAs for most things and are careful with their expiration.
Now show us the cost, the time it took, and how much babysit... sorry, "human supervision" was necessary.