SQLTeam.com | Weblogs | Forums

Backup succeeded but backup file nowhere to be found


#1

Hi, my dear experts,

Please help me figure out what went wrong.

I created these maintenance plan backups (full, diff and tlog), and they have been running "successfully", at least that’s their histories have shown. However, now upon a closer look, there were no backup files existed on the destination locations.

Months ago, they were there.

So here are what I have tried:

Cleanup job wipe them out? No, I run them ad hoc, still no file. And the job completes too fast, within a minute.

Destination permission issue? Unlikely: 1) it did not error out; 2) I verified that service account is on that network share drive and is the same account in history message Exec as user; and 3) my ad hoc run was able to create a subfolder on the destination with current time stamp.

High Availability issue? Maybe but why? My initial plans were setup before the AG was hookup, and now this box is the primary on a two node cluster. Following note is from the maintenance screen:
The selected backup type is not supported on a "Always on secondary replica"...
And sending me to Microsoft webpage : http://go.microsoft.com/fwlink/?LinkId=208213
Active Secondary's: Backup on Secondary Replicas.

But I am sure, I am trying to backup the primary.

Thanks!
Hommer


#2

On the local sql box create a folder c:\backup

Then backup to that location. See if it's a network issue or something else.


#3

Vinnie,

Thank you for your reply.

I did what you have suggested, but the result is the same. Folders were created but they are empty, no bak file inside.


#4

Obvious question but did you make sure to specify to use the .bak extension for your backups? There is an option in the maintenance place where you need to specify that.


#5

mfemenel,

Thanks!

I do have that extension there. I also have another backup for transaction log. They both failed to create a file at destination.

This is on SQL 2012 Enterprise edition.

I have another set of database with similar characteristics, which has been successfully backing up.

The only obvious difference is this set of database is for SharePoint 2013. However, SharePoint itself did not create the issue, because I had backed them up before they were hooked up for High Availability.

Any other ideas?

Thanks!


#6

My colleague figured this one out.

It is caused by an AG setting conflicts with maintenance plan.

Here is the msdn.