Budget Backups: Which is better



  • I haven't begun to move everything yet,.. but I'm thinking I'm looking at about 300GB of data what will need to be backed up....

    What would a few suggestions be?



  • The first question is... what platform(s) are you backing up? That matters a lot.



  • @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?



  • @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.



  • 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.