Budget Backups: Which is better
-
@scottalanmiller said:
The first question is... what platform(s) are you backing up? That matters a lot.
@ajstringham said:
@scottalanmiller said:
The first question is... what platform(s) are you backing up? That matters a lot.
Agreed. Are we talking physical or virtual machines? SQL? Exchange? Oracle? What is your RTO?
We have 3 applications that run SQL, though they have internal backup ability. They are physical machines currently. Email is Office 365, so that isn't as much of a issue currently ( though We have to have a retention policy due to Grants and HIPPA). nearly 85% of it is just documents; Excel,Word, PDF, JPG, PNG,
RTO - I know what that is,.. but for the moment, I can't remember..
-
So you need something to do SQL backups? From physical devices or virtual? [Edit, just saw that they are physical.]
-
Are you backing up SQL or are you backing up SQL backups?
-
@scottalanmiller said:
So you need something to do SQL backups? From physical devices or virtual?
It sounds like he's just doing maintenance backups, so I'd say yes, we need to get him a proper backup solution.
-
@g.jacobse RTO is Recovery Time Objective.
-
If you are on a budget, this is one of the places where being physical really catches you. On virtual both Unitrends and Veeam offer free backup solutions. On physical, not so much.
-
@ajstringham said:
@g.jacobse RTO is Recovery Time Objective.
It's useful but I find RTO a misleading tool because backup recovery doesn't work that way. Like update, it is about risks, cost and variables. RTO makes people act like it is a line where you either get this or that and this is the price. It is much more a curve.
-
@scottalanmiller said:
If you are on a budget, this is one of the places where being physical really catches you. On virtual both Unitrends and Veeam offer free backup solutions. On physical, not so much.
Oh so true.
-
@scottalanmiller said:
@ajstringham said:
@g.jacobse RTO is Recovery Time Objective.
It's useful but I find RTO a misleading tool because backup recovery doesn't work that way. Like update, it is about risks, cost and variables. RTO makes people act like it is a line where you either get this or that and this is the price. It is much more a curve.
Still, you have certain time frames you need to work within. This is a good metric to use as part of a total picture. It's not a standalone determining factor.
-
@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.
-
@scottalanmiller said:
If you are on a budget, this is one of the places where being physical really catches you. On virtual both Unitrends and Veeam offer free backup solutions. On physical, not so much.
Haven't Veeam just announced a free physical server backup product?
-
@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.
-
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.
