How can we help you today? How can we help you today?
alchemistmatt
When using v4.5 of Sql Backup I was backing up directly to a network share, was using ERASEFILES, but was not using FILEOPTIONS. With v5.0, I could still backup directly to a network share on 3 of my 4 servers, but not on the fourth (getting error "Process terminated unexpectedly. Error code: -2139684860"), and so I switched to backing up to a local disk and using COPYTO (also, a post mentioned this is faster and safer than backing up multi-GB databases directly to a remote share). Since I'm now backing up both to a local folder and then copying to a network share, I set FILEOPTIONS to 3, since I wanted old backups to be deleted from both the COPYTO folder (FILEOPTIONS=1) and the DISK folder (FILEOPTIONS=2). Based on your suggestion, I'll try FILEOPTIONS=1 and see if the trend is still there (I can wipe the local backup folder daily, so simply having Sql Backup auto-delete old files in the COPYTO folder will be acceptable). I had not noticed the archive flag exception for FILEOPTIONS=2 or 3; good to learn about. Still, the every-other-DB deletion trend is occuring both with or without the use of COPYTO, and is occurring regardless of the archive bit (the program is deleting files in a COPYTO folder even when the Archive bit is set since all of my backup files have the Archive bit set). / comments
When using v4.5 of Sql Backup I was backing up directly to a network share, was using ERASEFILES, but was not using FILEOPTIONS. With v5.0, I could still backup directly to a network share on 3 of...
0 votes
petey wrote: Would it be possible to send us a backup file that you are having problems restoring? I too am unable to send you any sample files, but for a slightly different reason. For every failure I've seen, the backup succeeded but the error occurred during the restore. Due to problems related to backing up over the network (for which, unfortunately, MAXDATABLOCK=524288 fixed the problem in Sql Backup v4.5 but does not fix the problem in v5.0) I switched to backing up to a local drive then using the COPYTO command to auto-copy the backup file to a remote server. However, if the backup is successful but the RESTORE VERIFYONLY command fails, the COPYTO command is not executed by the sqlbackup extended SP. Since I have setup a cleanup script that deletes files in my temporary (local) backup file every 12 hours, I therefore no longer have the files that caused the "Unexpected end-of-file". The behavior I would much prefer to see is that the COPYTO command is run if the backup succeeds but the VERIFY doesn't. Command used: exec master..sqlbackup '-SQL "BACKUP DATABASES [ORF_V27] TO DISK = ''D:\Redgate_Backup_Xfer\<DATABASE>\<AUTO>'' WITH NAME=''<AUTO>'', DESCRIPTION=''<AUTO>'', COPYTO=''\\proto-1\DB_Backups\Albert_Backup\<DATABASE>'', ERASEFILES=20, FILEOPTIONS=3, COMPRESSION=3, VERIFY, LOGTO=''F:\SqlServerBackup\'', MAILTO_ONERROR = ''username@mydomain.com''"' / comments
petey wrote: Would it be possible to send us a backup file that you are having problems restoring? I too am unable to send you any sample files, but for a slightly different reason. For every ...
0 votes
I have also seen the unexpected end-of-file reached error three times in the last two days, though it was appearing during an automated backup rather than during a manual restore. I am calling Sql Backup via the extended stored procedure, sending it a list of ~20 DBs to backup, and including "VERIFY" in the command to request that the backups be verified. Out of ~500 backups over two days, three of the backups failed the restore step with the log file showing Error reading file: unexpected end-of-file reached just after the "RESTORE VERIFYONLY FROM DISK" command was issued. This shouldn't be the result of network communication errors since the backup drive is inside the same server as the DBs reside. The Sql Server Error Log has this info 2007-05-07 06:13:10.01 spid65 Error: 18210, Severity: 16, State: 1. 2007-05-07 06:13:10.01 spid65 BackupVirtualDeviceFile::ClearError: failure on backup device 'SQLBACKUP_5968D447-699C-440E-86E9-35F095E485BE01'. Operating system error 995(The I/O operation has been aborted because of either a thread exit or an application request.). 2007-05-07 06:13:10.01 spid65 Error: 18210, Severity: 16, State: 1. 2007-05-07 06:13:10.01 spid65 BackupMedium::ReportIoError: read failure on backup device 'SQLBACKUP_5968D447-699C-440E-86E9-35F095E485BE'. Operating system error 995(The I/O operation has been aborted because of either a thread exit or an application request.). / comments
I have also seen the unexpected end-of-file reached error three times in the last two days, though it was appearing during an automated backup rather than during a manual restore. I am calling Sql...
0 votes