3 ms·

I also hear people say that all the time. Usually they're managing measly small 1-100 GB databases, not multiple ones > 1 TB in size. Restoring them in a regula

I also hear people say that all the time. Usually they're managing measly small 1-100 GB databases, not multiple ones > 1 TB in size. Restoring them in a regular basis is easy in that case. 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?)

Intermernet 8y ago
My DR procedure was to automatically restore the mail server, DB server and file server once a month with automated fail back to the live servers if they failed. 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.
Dylan16807 8y ago
I'm confused. Why does the number of restores affect how much space you need?
- AznHisoka 8y ago
  You're right, we could restore each, one by one. 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.
  - cheald 8y ago
    If you already have the DBs in S3, it seems obvious that you could bring up EC2 instance(s) with gigantic EBS drives attached, restore a DB to it, and run verification measures on it. Parallelize as your budget allows.
    - AstralStorm 8y ago
      EC2 is not an airgapped machine. That's known as cloud backup not offline backup. 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.
      - Dylan16807 8y ago
        > EC2 is not an airgapped machine. That's known as cloud backup not offline backup. 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.

Intermernet 8y ago

My DR procedure was to automatically restore the mail server, DB server and file server once a month with automated fail back to the live servers if they failed. 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.

Dylan16807 8y ago

I'm confused. Why does the number of restores affect how much space you need?

AznHisoka 8y ago
You're right, we could restore each, one by one. 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.
- cheald 8y ago
  If you already have the DBs in S3, it seems obvious that you could bring up EC2 instance(s) with gigantic EBS drives attached, restore a DB to it, and run verification measures on it. Parallelize as your budget allows.
  - AstralStorm 8y ago
    EC2 is not an airgapped machine. That's known as cloud backup not offline backup. 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.
    - Dylan16807 8y ago
      > EC2 is not an airgapped machine. That's known as cloud backup not offline backup. 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.