Budget Backups: Which is better
-
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.
-
@scottalanmiller said:
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.
Yeah, this shouldn't be a "I need to buy 2 or 4 HDDs". This should be looking at your total data size and planning accordingly. Scott's recommendation of a NAS that is stand-alone for backup is a great done. Disk is probably going to be your best option, as the cost isn't real high, and continues to go down, and the reliability is solid. If you want to save some money, use a NAS and use RAID1 with 4TB drives. A 2-bay NAS will give you 4TB, a 4-bay NAS could have 8TB with 2 RAID1 arrays.
-
@ajstringham @scottalanmiller
In restructuring, I'll have a box that I can drop drives in.. I have a PE t310 that I could retask,.. but it only has 250GB drives in it and only one Controller. I can't say it would be worth upgrading it.
I thought about using the PE 1800 since it had a 72DAT drive,.. but I think it is to limited ... There does get to be a point where dragging something alone just isn't practical.
-
IOSafe is nice because it is fire proof.
-
@scottalanmiller said:
IOSafe is nice because it is fire proof.
Uhm,.. Yea,.. I've been watching those.. I've also thought of building my own... At least for myself at home.
-
@g.jacobse said:
@scottalanmiller said:
IOSafe is nice because it is fire proof.
Uhm,.. Yea,.. I've been watching those.. I've also thought of building my own... At least for myself at home.
not sure how feasible that is to build yourself. It takes some engineering to make that able to be a working NAS, handle the heat, withstand the fire hose and survive reliably. The IOSafe device is impressive and yes, I have one.
-
@JaredBusch said:
@ajstringham said:
It sounds like he's just doing maintenance backups, so I'd say yes, we need to get him a proper backup solution.
For what? Adding in something to specifically backup SQL is just another layer to make a mess.
He has (I assume nightly) full backup files being generated by SQL. Just back those up. Nothing else needs done. No messing with SQL and potentially breaking it.
Jared -...
Uhm...It's not being done... Ad hoc at best... the guy before me was using some copy program to external USB drives,.. Not really safe.
-
@g.jacobse said:
Uhm...It's not being done... Ad hoc at best... the guy before me was using some copy program to external USB drives,.. Not really safe.
That is simple to remedy. Basic SQL maintenance jobs can auto create and cleanup backups. They will run nightly (or whatever schedule you want to set) and can be set to email you whenever they fail to execute.