From my blog at http://wss.com/en/resources/blog:
I was called in to consult at a site where the backups were exhibiting strange behaviour. The backup file was the normal 15Gb in size and the time stamp was from last night, but when they restored it in test there was no new data. In fact, the most recent data they could find was from a couple of weeks ago.
Looking at the DB log file, it didn't take long to ascertain that the backups were actually failing.
Read the rest here: http://wss.com/en/resources/blog/entry/ouch-backup-time-stamp-on-windows
From my blog at http://wss.com/en/resources/blog:
I was called in to consult at a site where the backups were exhibiting strange behaviour. The backup file was the normal 15Gb in size and the time stamp was from last night, but when they restored it in test there was no new data. In fact, the most recent data they could find was from a couple of weeks ago.
Looking at the DB log file, it didn't take long to ascertain that the backups were actually failing.
Read the rest here: http://wss.com/en/resources/blog/entry/ouch-backup-time-stamp-on-windows
Flag this post as spam/abuse.
Seems to me that the underlying flaw here is backing up over the top of an existing file(s)
@TMH your point is well taken. If the backup files are time-stamped then I need a routine to purge them or risk running out of disk space. We do this for AI files because we have to and we do time-stamped backups at sites that want more than one day of backups on hand. At small sites with limited admin staff we try to minimize complexity.
Point being, those files are ones last good backup or that last good backup has already been copied elsewhere. If the former, it should be saved in case anything goes wrong. If the latter, it is cleaner to delete before starting a new backup, most likely when the copy is complete.