But I'd love to hear how people practice restoring all their backups on a regular basis when it requires having an enormous amount of space. Practically, I just restore a few backups every month, and if it works, I just assume the others work as well (which I know is a false assumption, but what are you going to do?)
These would happen outside heavy operation hours, and if successful, the restored servers would become the live servers in most instances.
These were done using scripted vmware instances, mostly restoring from StorageCraft Shadow Protect backups.
File server was the most resource intensive and the most prone to complaints about downtime, but usually the trade off was fine.
DB server was usually fine due to the out of hours restore, and the ability to master - slave - replicate - handover.
Mail server was usually transparent as you could set up smtp transfer rules for incoming, and outgoing didn't really care.
The trickier ones were things like IBM I Series servers that usually require periodic full system saves, restores and tests. These couldn't be done automatically without excessive licensing fees and much manual baby sitting.
If you get to the point where you have automatic scheduled DR, you can be pretty confident your backups are working.
It the automated DR fails, you roll back, learn whatever lesson the failure taught you, and change the system so it doesn't happen again.
Summary: schedule DR, not backups.
However, we have around 30 different databases, each of which take more than a day to restore. We backup databases every X days, upload them to S3, and delete the previous ones, keeping only the last 3 or so.
So if it takes us 30 days to restore all the databases, those backups might already have been gone in S3 as part of the cleanup operation anyway.
It just gets complicated, and non-trivial when you have multiple databases, each TB's large.
The solution is to have a tape or disk library and have the other machine take over for restore. If you have TBs of data you can afford a library and another PC to run the recovery test.
Nobody said it was. This subthread is about the importance of testing backups in general.
> If you have TBs of data you can afford a library and another PC to run the recovery test.
They already explained how that's not enough. Yes, they can add more, but you're missing some info there.
I've tried various options over the years but I haven't found a simple OTS non-tape offline backup solution. There's a lot of potential here for a solution.
Usually those conditions aren't met properly.
You're definitely right, though; there's gotta be a better way. SSDs look promising, though not necessarily for long-term storage (for that, I suspect it'd be hard to beat optical, aside perhaps from printing out a bunch of QR codes or something).
Learned that lesson early in my career - the fourth and final tape did restore.
NB The backups weren't my responsibility, but restoring the payroll database my shell scripting error had nuked most definitely was.