October 10, 2013 at 7:42 am
Hi,
The company i work for currently use Veeam to replicate an SQL Server instance every morning at 3 am (this involves taking a full backup of each database).
They also use DPM to backup the databases, an express full backup takes place at 2 am and then synchronization takes place every 15 miuntes.
I was concerned that the backup chain might be broken by the two products running full database backups on the same databases. To test this i executed a full backup using DPM; made some changes to a database and then ran the replication job within Veeam (which takes a full backup). I then allowed a number of DPM synchronization jobs to run (log backups) before restoring the database from DPM.
The restore was successful despite the fact that the log chain should have been broken (as far as i can tell).
If anyone is able to make sense of what i have written and can offer and suggestion as to how this restore was able to succeed i would be very grateful to know.
Kind Regards,
DBANewbie.
October 10, 2013 at 8:24 am
Hi SSC -basically when Veeam backs up (or replicates) a SQL VM, we do use VSS to quiesce the VM, file system and application (Hyper-V or VMware). Our requestor also truncates SQL logs, optionally. Backup jobs have this on by default, replication jobs do not.
But it's important to note that in the SQL application log, our process does not mark the DBs as being backed up. So if a SQL Server Agent job or Maintenance Plan runs that will backup the DBs - they do mark it as backed up. Make sense?
FYI, I work for Veeam.
October 10, 2013 at 8:37 am
Thanks for your response, i think i have managed to peice together what is happening.
Our Veeam replication job is not set to truncate the logs; it simply performs a full database backup so it does not actually impact the backup chain. DPM is the only package performing log backups so that is why we can always restore using that software.
October 10, 2013 at 8:46 am
That's what it looks like to me.
For the curious... "WHY" doesn't Veeam mark the SQL app as backed up? Well, it's because we are doing an image based backup. Yes, it's application consistent. Yes, we can do granular recovery. Yes, we can do log truncation. But b/c the whole image is taken; that's why we don't mark it in SQL.
October 10, 2013 at 8:54 am
At risk of asking a silly question, does this reduce/remove the need to back up databases within SQL Server for recovery purposes?
Thanks
October 10, 2013 at 8:56 am
If point in time recovery (dial back logs) are required, you'd still need SQL agent backups. If not, our image will be fine.
October 10, 2013 at 9:00 am
Thanks. So if an image is taken every hour (would it be? Is that likely?), and up to an hour's data loss was considered acceptable, bam, no need for SQL Agent backups?
October 10, 2013 at 9:02 am
Yeah, some people do replicate or backup hourly with SQL VMs and Veeam.
As long as the storage can handle that extra I/O during the day - should be good.
October 10, 2013 at 9:14 am
Thanks; sorry if that was a hijack.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply