Kaseya Community

How reliable is BUDR - do you test your backups

  • Hi folks,

    We are using BUDR for a continuity solution for clients so we are making nightly images of their servers to a local device.

    My question is - over the last while our number of clients has increased and in the early days we used to a monthly test of the backup so we would build the VM and power it up to ensure it works.

    Problem now is that with all the new clients it is getting unmanageable and by the time you finish the last client test it has nearly come time to start the first again. We have a guy spending a lot of time doing this.

    Are you guys testing your images and if not are you confident or covered to not test them and if they fail when the client requires them so be it.

    Are you happy with the fact that the backup says it ran and might have verified (get a lot of failed verifys).

    Thoughts on a postcard please

    M

    Legacy Forum Name: How reliable is BUDR - do you test your backups,
    Legacy Posted By Username: mmartin
  • I like this request and too in need of knowing how others are testing. As well want to keep tech time to a minimum on this.

    My thoughts are, since this is Kaseya and automation is the key to this RMM Solution, why can't we have a automated way to test backups to assure we with little intervention but 100% certainty.

    I would love to see an automated script that allows us to convert .tib to .vhd on a scheduled basis. Also a script that would open an archive and recover data automatically as a test.

    This way a quick test of starting a .vhd file to assure it will boot is all that a tech would have to complete.

    Kaseya's tag line "Our Automation Your Liberation". I ask Kaseya to liberate us ways we can automated backup restores with scripts to save us time and money!

    Joe Axne
    IT-Guru, LLC

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: itgurullc
  • You have to trust it. Every once and a while I do a Verify on the backup set to make sure it checks out.

    On a server I will make sure the Acronis Universal Restore CDROM boots. If it doesn't boot, or acts weird, or doesn't have NIC drivers or whatever, I will use StorageCraft.

    Workstations have always booted the CDROM. I can dig out data, or convert or somehow massage workstation TIBs to get the client data. My Workstation SLA's are not very tight.

    Servers I need to be rock solid. Some machines that won't boot the Acronis Disc get the StorageCraft backup. I actually like StorageCraft better, but their MSP server pricing is 6x the price.

    I don't really do the virtual thing much just yet. I can see how loads of conversions, copying the virtual images, and loading would be cumbersome.

    I don't have the time to do a complete 100 percent verification on every single backup I've done. Maybe I'll write it into the process to do a full virtual verify once a month per machine and stagger it across the month with a few a day.

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: FarVision
  • I've been using BUDR for 2 years now and finally had an situation where I needed to restore a critical client workstation. I had a full backup + 6 incrementals - I discovered that all of them were corrupt and could not be restored as an image.

    By dumb luck, one of the TIB files could be 'explored' on a system with Acronis installed (right-click, explore image - but could NOT be 'mounted' as a drive letter) and I was able to manually copy out the client data and rebuild the system, but it was a 4 day ordeal (extremely slow copy from the Acronis image and a very large data set).

    Needless to say, I wasn't happy about this. What happened was that a full backup failed due to a full disk (even though it was supposed to delete the oldest set first). After the full backup failed, it continued the next day to create incrementals in the same destination folder as the 'good set' and basically corrupted the 'good' incrementals that I had already created.

    Support admitted this was a bug and will be working on some sort of fix. What really got me though was that they said 'if you were using 'verify' you would've caught this sitation since the verify would have failed', but in the same breath admitted that verify 'isn't reliable in every environment and shouldn't be used if you are experiencing any issues with it'. As others have posted about, we use verify but many, many times it fails for no reason and subsequent tests of the images show they are actually ok.

    To me, this is unacceptable - if you're selling me a product for 'backup and disaster recovery' but then tell me its only method of integrity checking is totally unreliable, then this product isn't worth much to me at all.

    We do 'test restores' also at periodic intervals, but this only exercises your restore process, it doesn't really tell you if the image is going to be good when you need it. At this point, support hasn't been much help in giving me an answer as to how I'm supposed to reliably use BUDR in its current state. I don't feel good about the position I'm in, especially as I take on new clients and am making backup/disaster recovery promises.

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: benny@geeksaknockin.com
  • benny,

    wow... that situation is very disapointing to hear.

    I can tell you that we were havign problems with Verifies always failing, and K Support suggested that we discontinue the Verifies.

    We have to be abel to rely on these backups.

    Lloyd

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: lwolf
  • I agree completely.

    My question to Kaseya (still unanswered satisfactorily) is 'what do I need to do to know that my backups are good?' If they can't provide an answer to this question, then they ought to be looking for a better backup vendor to use.

    The myriad different backup/verify failures we experience are ever changing and hard to pin down. At any given time about 5% of my backups fail on one client or another. Support throws me back on the hamster wheel of 'try this and try that' but without really being able to source the root cause of the problems.

    I don't sleep well at night with this current setup - if Kaseya tells me to turn off verify, then I have zero confidence that the backups are good, especially after my last experience. I know others that have used BUDR in a live recovery numerous times without incident, but it still doesn't give me any comfort. I feel like I'm just rolling the dice here and considering the amount of money spent on the product and **support and upgrades** I think we deserve a much better solution.

    I'm supposed to have a conference call with someone from the BUDR team to discuss their future roadmap but haven't been able to schedule that yet. New features would be nice, but nicer still would be a reliable product that we can count on to do what it promises to do.

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: benny@geeksaknockin.com
  • I don't do the verifies, what I do is randomly mount images (via kaseya), then randomly pull images for restore... I've had only a few fail, these were the first few backups ever done. I chalk those up "the learning curve".

    When i do the restores I do them one of 2 ways either Image to VM (I use VMware in house so thats my natural selection), or restore to one of the dev boxes I have lieing around with the drive space to handle what ever image I'm restoring.

    The reason why I don't use verify is because I never really understood how it worked... I've clicked it a couple of times and it said all was good, but if I dont need to I wont... call me lazy.

    For the record, this is just my opinion, but BU-DR isn't the best for servers as it is not Exchange aware nor is it DB aware... there are just too many steps to take that can fail for a proper backup to be done on a server. Again this is just my opinion, others have been successful with doing it, but I only run BU-DR via Kaseya on workstations.

    Edit: Also worth noting, we've used several different backup solutions, none of which are fool proof and work all the time.

    Anyways I hope that my "style" of things answers your question...
    In short, I don't believe it unless I or someone within spitting distance can do it... It's not an anti-BU-DR thing its just the way I am.

    Edit: If you would/could share your BU-DR basic configuration, and points of failure... maybe others with more success can help.

    My biggest pain was space for images, now I have a simple formula, total drive space to be backed up (this includes free space) x 5 is the minimum required for us to do any type of onsite backup. And even this is going to become an issue as more and more TB workstations show up... but until then, this part of the forumla works...

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: thirteentwenty
  • thanks folks for all your feedback - I agree with all.

    We had an issue with one client where a whole months worth of incrementals and the full were corrupt - we think it all stemmed from the original full being corrupt. Luckily we had two months worth of data but reality was we were offering previous day restores which we could not deliver.

    Verify for us is a nightmare and the fact that it can take as long as a full in some cases 7 - 10 hours is stupid and most of the time it fails and then as you said even if it succeeds no guarantee it is all working.

    Not sure where to go here really K have us by the B@£ls really as we have bought licenses but I am not convinced by the product or its reliabilty.

    Keep the thoughts coming though.

    m

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: mmartin
  • The verify caused us no end of trouble, until I turned it off. I had a ticket open with Kaseya for over 2 months with no resolution; I finally discovered that the verify was cauisng it. An incremental backup was between 2 and 5 times LARGER than the entire used space of the hard drives (and could not be restored from). I turned the verify off, everything started being the right size and recoverable.

    Here is a quote from Kaseya Help file: "Verification does not involve comparing the backup to the original source files, so any other machine with an agent can be used to perform the verification of the backup file so long as the machine has read/access to the image location."
    Kaseya support tech told me that the verify DOES compare the backup to the original source files. So a database=almost certian verify failure.

    Another quote form the help file: "Verify takes the same amount of time as the original backup to complete. Only verify in situations where you question the integrity of the network connection to the backup file location. You do not generally need to use this option".
    We all know that the verify does NOT take the same amount of time, it is generally much longer. And Kaseya says yes you need to run the verify while there help file says no, don't use it.

    KASEYA: Make up ur mind!!

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: JonJohnston
  • benny@geeksaknockin.com
    My question to Kaseya (still unanswered satisfactorily) is 'what do I need to do to know that my backups are good?' If they can't provide an answer to this question, then they ought to be looking for a better backup vendor to use.


    Saw this a while back: http://www.reuters.com/article/pressRelease/idUS168138+13-May-2009+MW20090513

    It would seem that Kaseya is looking for a better backup vendor... And perhaps they've found one. If AppAssure can really do what they say, then I'll be impressed. But then again, if BUDR really did what they said, I'd be impressed.

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: arobar
  • I'll add my verify mystery to the pot:

    We were supplying WD Passport Essentials to our laptop clients for backup and kept getting verify failures. If we backed up to a NAS drive or other external drive (including a WD Elements, which we supply now), no problems.

    If we copied a backup that passed verification from a drive to the WD Passport Essentials, it would fail a verify.

    Poking around on some Acronis forums, it appears that some USB drive chipsets (we tried an ACOMDATA enclosure and had the same problem) miscalculate/mangle the checksum, causing the verify to fail.

    Only Acronis seemed to have a problem with these drives. Spinrite and Windows could read/write data without problems...

    We rarely get a verify failure now, and if we do its usually caused by a machine rebooting in the middle of it or some other hadware issue.

    Jeff

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: JMF
  • I had a conversation today with Mike from Kaseya (from the BUDR team from what I gather) and we talked at length about the verify issues. He also talked about the upcoming BUDR roadmap a bit.

    He confirmed that the verify process has issues, no surprises there. He said that their investigation so far have found that a lot of the verify failures/errors result from network latency. They have a 3.1 build of BUDR that has added 'retry logic' and so far has seemed to resolve the problem in those who are on that build. I think he said that only 5 or so customers are using that, but he's going to make sure I get a copy of it to test. We still have a fair amount of clients using USB drives rather than NAS's so it remains to be seen how much help it will be overall, but at least it's a shot.

    They are actively working on getting the integration done for Acronis v10, which apparently moves back to using Microsoft's API for VSS snapshots, in the hope of fixing the 'grey screen' problems being reported. No timeline given on that, but he also mentioned late Q2 timeframe for getting the 'application aware' Acronis code into BUDR (Exchange/AD/SQL), so that is something else to look forward to.

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: benny@geeksaknockin.com
  • thirteentwenty
    just my opinion, others have been successful with doing it, but I only run BU-DR via Kaseya on workstations.

    --- what do you do for servers?
    --- what does that do to your cost structure?

    Edit: Also worth noting, we've used several different backup solutions, none of which are fool proof and work all the time.

    --- been doing this since 1981 and thats why I lik using 2 or 3 different kinds of backup eg. ntbackup + budr/besr/whatever + mozypro/whatever. but as we rollout more clients mgmt becomes the issue.


    Anyways I hope that my "style" of things answers your question...
    In short, I don't believe it unless I or someone within spitting distance can do it... It's not an anti-BU-DR thing its just the way I am.

    Edit: If you would/could share your BU-DR basic configuration, and points of failure... maybe others with more success can help.

    My biggest pain was space for images, now I have a simple formula, total drive space to be backed up (this includes free space) x 5 is the minimum required for us to do any type of onsite backup. And even this is going to become an issue as more and more TB workstations show up... but until then, this part of the forumla works...


    --- 5x what is your schedule/retention period
    thnx

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: razmataz
  • JMF
    I'll add my verify mystery to the pot:

    We were supplying WD Passport Essentials to our laptop clients for backup and kept getting verify failures. If we backed up to a NAS drive or other external drive (including a WD Elements, which we supply now), no problems.

    If we copied a backup that passed verification from a drive to the WD Passport Essentials, it would fail a verify.

    Poking around on some Acronis forums, it appears that some USB drive chipsets (we tried an ACOMDATA enclosure and had the same problem) miscalculate/mangle the checksum, causing the verify to fail.

    Only Acronis seemed to have a problem with these drives. Spinrite and Windows could read/write data without problems...

    We rarely get a verify failure now, and if we do its usually caused by a machine rebooting in the middle of it or some other hadware issue.

    Jeff


    been using seagate freeagent go (with docking station when used for offsite from NAS). only issue i have seen, and this has been consistent across most usb drives, is an Error 51 which research has shown to be ignorable ... at least so far).

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: razmataz
  • our testing of BUDR backups has not been formalized/scheduled.

    prior to using BUDR (and kasdya for that matter) we encouraged our end users to buy both BESR and tape based backup (BEX, ARCserve, or we use NTBackup) so we would have wo kinds of backups on two kinds of media.

    We would then, for a nominal fee of $50, have tape sent back to our shop to confirm readability once a year or so. If the image bkups fit on the tape we would do a restore and see that at least one of the images could be opened with BESR.

    Obviously this is not a DR test.

    We used to shutdown/restart exchange/sql for the BESR jobs (these custs are not 24/7 operations with highly active mail/sql) but stopped that practice when symantec support said that was no longer necessary. We did have occasional issues when exchange would not fully come up in the post snapshot script for reasons we never fully understood but suspected had to do with timing (a manual start of the appropriate service would then do the trick - we did not implement a scheduled test/remediation script)

    We did not have the cust cycle the image backups offsite by changing the usb drive. we were happy if they were able to change their tapes (most of the time).

    SO that brings us to BUDR and an evolving change of strategy to D2D2D and the consequent elimination of tape.
    1.Utilize a NAS (with raid - settled on Readynas) as the backup destination and then a USB drive connected to server or a workstation with a scheduled synch job and some custom scripts for offsite rotation (weekly or monthly depending upon client's needs). Not using the readynas usb connectivity at this time. Testing but not yet satisfied with readynas vault (their offsite by the wire component possible useful for flat files of modest size i.e. not gb sized images). Testing their RSYNCH to a 2nd NAS on the LAN (which does not address offsite)
    2. Utilize offsite over the wire backup for the most critical data. We are using mozypro at this time at a few locations (but their daily deltas are relatively small)
    3. We do an initial test open of an image or two as well as a restore of a file or three from mozy - and so far thats been it for testing. Not satisfied that this is enough but also having trouble increasing the fees to do more - this is a value/sales issue for the smaller client who expects that now that they are doing backups that the restores will work everytime.

    We have yet to try BUDR offsite server though that is on the list. Read with great interest those that are using/trying in the cloud offsite virtual - server destinations. We are not prepared to do up our own offsite storage in h ouse and have not done the math to see how many offsite backups we would need to be running to justify dedicated rack space at the local and secure ISP datacenters.

    We have Zenith in the potential mix for the more sophisticated client (using it in house in combination with tape) but zenith does not support workstation backup. Its integrated in the box VM is what is attractive (they use storage craft plus a bunch of open source bits). We are no enamoured of their support (nough said?)

    If it is not obvious yet - I continue to expend some serious mips mulling things over and am not yet satisfied that we have a viable (technically or financially) backup and DR solution - and am wondering if we will ever given that software stinks (actually had another word in mind) and especially backup software stinks.

    and though forums are usually more filled with issues than happy thoughts it sure seems the acronis really stenches for many.

    sorry for the ramble.

    z

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: razmataz