Budget Backups: Which is better
-
RTO isn't completely useless, but it is critical that everyone involved understand that it is an objective and that the value is highly subjective and should never be seen as an SLA and should be up for business interpretation. Otherwise using an RTO can heavily lead you astray. If you don't understand the guidelines that were used for coming up with the RTO, the RTO is useless, and if you have those guidelines, you don't need the RTO.
-
@Carnival-Boy said:
Haven't Veeam just announced a free physical server backup product?
They have one for desktops. Do not know its limitations yet.
-
@Carnival-Boy said:
Haven't Veeam just announced a free physical server backup product?
@scottalanmiller said:
They have one for desktops. Do not know its limitations yet.
Also not out until Q1 2015 I believe.
-
@scottalanmiller said:
@ajstringham said:
Still, you have certain time frames you need to work within.
That's the thing, you don't. Believing that there are time frames without a cost context is the mistake that talking RTO makes people make.
I'm not sure what you mean. There are some servers that you need to be able to recover within certain time frames. It's one of several factors to consider when choosing a solution.
-
@scottalanmiller said:
RTO isn't completely useless, but it is critical that everyone involved understand that it is an objective and that the value is highly subjective and should never be seen as an SLA and should be up for business interpretation. Otherwise using an RTO can heavily lead you astray. If you don't understand the guidelines that were used for coming up with the RTO, the RTO is useless, and if you have those guidelines, you don't need the RTO.
I agree with this.
-
@scottalanmiller said:
@Carnival-Boy said:
Haven't Veeam just announced a free physical server backup product?
They have one for desktops. Do not know its limitations yet.
They say it supports Windows Server 2008 and higher, but seem to be marketing it as a desktop backup, so I'm slightly confused.
Beta version out next month. Not sure you'd want to rely on a Beta version for live backups though.
-
@Carnival-Boy too early to be using it now. Excited to take a look soon, though.
-
I've never bothered to calculate an RTO. I suppose in the back of my mind I have some idea, but I've never formalised it or given my bosses any indication of what it is.
In reality, in a disaster situation, the time it takes to restore a backup is only a small proportion of the total downtime. This is because during a disaster I will normally attempt to fix the live system, which takes time, and will only restore from backup as a last resort.
So whilst officially my recovery time is about 4 hours, it could be easily be 12 hours once I've ran around, tried different things, raised a support call with HP, waited for an HP engineer, etc etc. I imagine in an enterprise environment disaster recovery would be far more formal, but in an SMB I'm sure I'm not alone in flying by the seat of my pants when disaster strikes.
-
This post is deleted! -
@Carnival-Boy said:
I've never bothered to calculate an RTO. I suppose in the back of my mind I have some idea, but I've never formalised it or given my bosses any indication of what it is.
Normally an RTO is something that they give you to meet, not something that you give them that you will meet.
-
@Carnival-Boy said:
In reality, in a disaster situation, the time it takes to restore a backup is only a small proportion of the total downtime. This is because during a disaster I will normally attempt to fix the live system, which takes time, and will only restore from backup as a last resort.
It can be very hard to calculate. Typically RTO is used by firms that have warm or hot standby systems and they have a set procedure for failing over to them with a rough calculation of restore time and failover time. So they can really predict a failover taking ~25 minutes or ~48 minutes or whatever and can talk about the cost associated with shortening that.
In an SMB where typically a disaster means "fixing the unknown" before restoring, RTO doesn't mean much.
-
@scottalanmiller said:
Normally an RTO is something that they give you to meet, not something that you give them that you will meet.
Maybe. Depends on the where the IT guy fits in the organisation, I guess. I'm not going to start another discussion with you on the correct separation of responsibilities and duties of IT though.
-
@Carnival-Boy my point is that the RTO is meant to be the amount of time that the business can withstand downtime. Not the amount of time that IT will have downtime. Regardless of separation, RTO is supposed to be the target to meet, not a reading back of what target is likely to be met.
-
Ah, got ya and that's what I mean by RTO as well.
Although, once you've put a recovery process in place - the RTO and the actual recovery time is supposed to be more or less the same, otherwise you may have over or under specified your solution.
-
@Carnival-Boy said:
Ah, got ya and that's what I mean by RTO as well.
Although, once you've put a recovery process in place - the RTO and the actual recovery time is supposed to be more or less the same, otherwise you may have over or under specified your solution.
Sure, I would say it like this...
RTO is expect to roughly equal RTE (where O is objective and E is expectation.) E would need to be slightly smaller than O to safely meet the objective reliably, of course.
-
Other than the program to use,.. Are hard drives better? USB External or Some other type?
-
@g.jacobse typically your main options are:
- disk arrays (SAN, NAS, DAS, etc.)
- tape (LTO typically)
- cloud (Amazon S3, Rackspace, Azure, etc.)
Using USB and other manually removable drives can be used in special circumstances, but generally not. The big three really cover the bulk of the use cases because they are more automated, scaleable and reliable.
-
@scottalanmiller said:
@g.jacobse typically your main options are:
- disk arrays (SAN, NAS, DAS, etc.)
- tape (LTO typically)
- cloud (Amazon S3, Rackspace, Azure, etc.)
Using USB and other manually removable drives can be used in special circumstances, but generally not. The big three really cover the bulk of the use cases because they are more automated, scaleable and reliable.
Yup. This.
-
@ajstringham said:
@scottalanmiller said:
@g.jacobse typically your main options are:
- disk arrays (SAN, NAS, DAS, etc.)
- tape (LTO typically)
- cloud (Amazon S3, Rackspace, Azure, etc.)
Using USB and other manually removable drives can be used in special circumstances, but generally not. The big three really cover the bulk of the use cases because they are more automated, scaleable and reliable.
Yup. This.
Manually removable drives are in use now,.. and one is in recovery at only 20% image (been in the clean room since Oct 3rd).
I have some (OLD) tape equipment. but i feel that won't be enough - not to mention the age of the drive and tapes.
-
Storage for backups is something you want to typically invest heavily in. Enterprise shops typically backup to disk, then to tape and then ship tape to offsite storage (e.g. IronMountain.) It's extremely costly at any scale. Backups are probably the most important cost center that a business can have. They aren't cool or flashy but they are where the money matters.
You don't need to go to IronMountain as a normal SMB, but you need to invest in your backups. This might mean getting a small NAS device like IOSafe that can sit on the far side of the building and backup to that. Even that leaves you at risk of building loss. But it is a start. Single drives are going to fail. Drives are not meant to be plugged and unplugged, moved around, etc. That makes them very likely to fail.
If you need to remove the device, look at tape. If you want it to be stationary, look at a disk array. But don't look at individual drives.
