July 6, 2020 at 7:03 am
To shorten a long story, my organisation has decided to have a vendor perform daily full backups using "Backup Product A" whilst the DBA will perform transaction log backups using "Backup Product B". The recommendation to use 1 system overall was overruled.
In the event a restore is required it will be the DBA's responsibility to ensure point in time recovery.
My question: has anyone had the experience of implementing a backup/restore process where two different products are utilised? One for full backups and another for transactions.
July 6, 2020 at 9:09 am
Probably not a very good situation to be dealing with. Are both products compatible with each other? How is each product doing backups? Do they use the VSS writer, are they doing native backups?
Can the FULL backup be restored from the appliance in a NORECOVERY state and then the transaction logs restored from the other appliance without any issues.
Can both products give you the companies combined RTO and RPO.
Get the vendors to show you how they can work together and if they can't and you can't meet the companies RTO and RPO then you have a major issue on your hands.
Generally everyplace I consult in follows the same rule, Native backups however that may be done Maintenance Plans / Ola Hallengren / In House written stuff to a disk or a fileshare, then 1 backup software comes in incrementally and copies them to tapes/virtual tapes/backup appliances. If something is backing up the database that's not native it is usually something like Quest Listspeed or Red-Gate SQL Backup. Things like CommVault are never used to backup the database directly due to limitations on past experiences where certain functionality cannot be done to meet companies RTOs and RPOs.
July 6, 2020 at 2:17 pm
I'd be curious about which two products and why can't 1 do both. Not questioning your situation, but just trying to understand.
For your question, I've only run into this with a mistake. We had a product doing compression for everything, but someone added in full backups with native algorithms. The easiest thing to do here for a recovery was convert the log backups back to native.
I think we tested the restore, and as along as the restore with Norecovery/standby was done, we could use the third party product to add the log restores.
NOTE: I would never endorse or recommend this. We could go from a bad situation to a horrible one if someone makes a mistake switching between products. When you restore, stress and pressure become an issue, so we want the absolute easiest, simplest thing ready. I would argue vehemently against using two products.
The being said, if I had to do this, I'd practice often, so the staff understands what to do.
July 6, 2020 at 3:14 pm
The recommendation to use 1 system overall was overruled.
I know you already know this but I have to say it out loud (and it's NOT aimed at you... you're the victim here)... This is the dumbest management-driven decision I've heard of in a long time.
That being said, I'm really curious why management thinks this is a good idea if you'd care to expound without getting yourself into trouble for doing so.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 6, 2020 at 10:51 pm
Can the FULL backup be restored from the appliance in a NORECOVERY state and then the transaction logs restored from the other appliance without any issues.
<snips>
Native backups however that may be done Maintenance Plans / Ola Hallengren / In House written stuff to a disk or a fileshare, then 1 backup software comes in incrementally and copies them to tapes/virtual tapes/backup appliances.
Thanks for your questions, those and a bunch of others I'll put to the vendor at an expected meeting.
Your "general rule" was how things ran previously, but I had concerns. We They were recently using VEEAM Enterprise which did a nightly sweep of all servers, and which can perform log backups and truncation if the configuration is set, but I had concerns. VEEAM Enterprise should have been able to allow a PIT recovery without too many shenanigans if it had all data required, but I was not able to verify if things were 100% (I haven't used VEEAM.)
July 6, 2020 at 11:06 pm
I'd be curious about which two products and why can't 1 do both.
I think we tested the restore, and as along as the restore with Norecovery/standby was done, we could use the third party product to add the log restores.
We They were recently using VEEAM Enterprise whilst I used Ola. I noticed some things and investigated VEEAM and found it should have been a one-stop-shop with the right configurations. Which I attempted to push.
However I've just got back from leave and found that now we are using ArcServe, and I'm just responsible for 'transactional' data backups coz the vendors will do the nightly backups of all servers. I'll need to discontinue full/diff backups, and still guarantee PIT recovery. The process as to how a recovery will work is TBD. (Hence this thread.)
It all hinges I figure on the vendor being able to do a no recovery restore with ArcServe first, then I can step in with the log restores.
July 6, 2020 at 11:36 pm
Fal wrote:The recommendation to use 1 system overall was overruled.
I know you already know this but I have to say it out loud (and it's NOT aimed at you... you're the victim here)... This is the dumbest management-driven decision I've heard of in a long time.
That being said, I'm really curious why management thinks this is a good idea if you'd care to expound without getting yourself into trouble for doing so.
To paraphrase GoT: "The nightly backups are murky and full of terrors."
There's a bit of history that leads to this point, going back prior to the use of VEEAM which I've mentioned in earlier posts. What this means overall is that there's a number of factors and management is picking the best option. They might want a brand new shiny car, but if they can only choose from the 2nd hand car yard then they gotta pick one of what's on offer.
The factors aren't all technical, nor budgetary. There's some cultural and historical as well. In theory the plan works and we just need to refine the process and test it. It's a situation that is evolving.
If, on a professional level, you'd like a bit more detail then I'm happy to take it to a private forum.
July 7, 2020 at 6:00 pm
Thanks for the notes and good luck. I think you're on the right track with verify PIT.
Be sure you can do this within your RPO/RTO, and give numbers to the others as they make their decision. Good to have a number of times (go back 10 minutes, 1 day, 2 days, etc.) and account for a few failure scenarios
July 7, 2020 at 7:14 pm
now we are using ArcServe, and I'm just responsible for 'transactional' data backups coz the vendors will do the nightly backups of all servers.
Doing a quick Google search shows that ArcServe does support transaction log backups:
https://support.arcserve.com/s/article/202854975?language=en_US
So what was the resistance to using the features of the product?
July 9, 2020 at 7:44 am
Fal wrote:now we are using ArcServe, and I'm just responsible for 'transactional' data backups coz the vendors will do the nightly backups of all servers.
So what was the resistance to using the features of the product?
Well, there wasn't resistance to using the features of the product, per se. 🙂
To oversimplify in a public forum, ArcServe backups are for asteroid-strike DR scenarios and transactional backups are for when users accidentally delete data. Two different scopes needing two different solutions, plus a host of historical and cultural reasons.
July 13, 2020 at 3:45 pm
And what is the vendor's turn-around time ? Do you have to contact them, open a ticket, and twiddle your thumbs waiting for a restore ?
"....It all hinges I figure on the vendor being able to do a no recovery restore with ArcServe first, then I can step in with the log restores....."
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply