|
There seems to be a "Day" for any occasion. Today, September 28, is Ask a Stupid Question Day. Here are some questions you might *think* you should know, but you've got some nagging doubt. And you're not sure you should be talking about that out loud. Because, you know, everyone else seems so calm, cool, and collected!
Q: Should I put my database on the cloud?
A: That's a big question! And I ask it without trying to lead you to any particular conclusion. (And I am supportive of whatever option you decide.) Some things to think about: Where is your database now? Where is the rest of your infrastructure that your database communicates with or requires? At a data center? Your office? Some of it on the cloud? (They should probably be together or at least in a place that has a substantial, high speed interconnect to the other components.) Do you have a system admin, storage admin, network admin, security specialist? Is your non-cloud environment secure? Resilient? Performant? Does your current solution meet regulatory requirements regarding security, resilience, privacy, etc.? Do you know how much it costs for you to host your environment non-clouded? How much will it cost for you to be on the cloud? How much will it cost for you to get off the cloud if you change your mind (for example, data egress)?
This is not a stupid question. There is a lot to consider in making this choice. The trend is toward the cloud, in order to take advantage of economy of scale, rich offerings, geographic diversity, compliance, resilience, and ease of use, among others. Some organizations on the cloud are moving back to their own data centers or own offices due to cost, lack of control, and other factors. Some organizations use a cloud-on-site solution where the cloud vendor puts vendor-owned equipment in the customer's data center and inside the customer's local network, often literally and figuratively in a cage.
Q: How many hours of data can I afford to lose?
A: Let's say you have a disaster and you are able to recover your data, but only up where it was an hour before the disaster. So, you will lose an hour's worth of data. Is that OK?
The name for a pre-determined amount of acceptable data loss is a Recovery Point Objective (RPO). I've seen RPOs ranging from zero data loss to a month of data loss. This is a no-judgment zone: if the the RPO meets business requirements, and the right people and technical infrastructure are in place to meet the RPO, then the RPO is right for the business! (Even that cringe-y sounding one month RPO. I know the factors the organization used to decide the RPO, and it's an adequate RPO for them.)
An RPO is not a technical decision. It's a business decision. If you are a technologist and you decided your company's RPO without conferring with business leadership, this could lead to a resume-necessitating event for you someday. If you are a business leader and don't know what your organization's RPO is, talk to your technology team to be sure that (a) there even is an RPO established, and (b) the RPO is OK with you. Otherwise you, too, could experience a resume-necessitating event.
So, it's not a stupid question. It's very important! Have this critical discussion soon, if you haven't yet.
Q: Are my backups good?
A: Try restoring them. That's the only way to be sure. In this process, you might learn some interesting things. Examples: your backups are incomplete; your backup type is inappropriate to your needs; you actually don't know how to do a restore test; your recovery plan documentation is outdated; only one person has the enough privilege to perform a restore; only that guy who resigned last week has access to your data center; it takes unacceptably long to restore your environment; you disagree with your scorekeeper about what your RPO is.
So, this is also not a stupid question. It's one that must be asked over and over. Even small changes can torpedo a solid backup strategy.
| 
