Comments
Sort by recent activity
A common cause is when the connection to the network share is lost during the copying process. When SQL Backup then reattempts to copy the file at a later time, it detects the incomplete file and chooses not to overwrite it. To resolve this, use the option to overwrite existing files in the COPYTO location in the backup command via the FILEOPTIONS parameter. If you are not currently using the FILEOPTIONS parameter, then add FILEOPTIONS = 4 to the backup command. If you are already using FILEOPTIONS, add 4 to the current value. For more details, please see the FILEOPTIONS section in the help file (https://documentation.red-gate.com/sbu/scripting-sql-backup-pro/the-backup-command) / comments
A common cause is when the connection to the network share is lost during the copying process. When SQL Backup then reattempts to copy the file at a later time, it detects the incomplete file and ...
It appears that the database cannot be restored to its original location, because the path/folders do not exist on this machine. Try running this command: EXEC master..sqlbackup '-sql "RESTORE FILELISTONLY FROM DISK = [<backup file name>]"'to see where SQL Server will attempt to create the database files in. Create those folders first if possible. If not possible, then use the MOVE options to create the database files in a new location e.g. EXEC master..sqlbackup '-sql "RESTORE DATABASE mydb FROM DISK = [<backup file name>] WITH MOVE [mydb_data] TO [<fully qualified data file name>], MOVE [mydb_log] TO [<fully qualified transaction log file name>] " ' / comments
It appears that the database cannot be restored to its original location, because the path/folders do not exist on this machine. Try running this command:EXEC master..sqlbackup '-sql "RESTORE FILE...
Hi, could you please send me (peter.yeoh@red-gate.com) the RESTORE command you were using for the command line restore? I could not reproduce the situation where using the NOLOG option still caused SQL Backup to create a log file, then subsequently delete it. I would like to see which options were used, that may have changed how NOLOG works. Thank you. / comments
Hi, could you please send me (peter.yeoh@red-gate.com) the RESTORE command you were using for the command line restore? I could not reproduce the situation where using the NOLOG option still cause...
Hi, there is a syntax error in your RESTORE command that the SQL Backup parser did not detect. Look for the first REPLACE keyword. There is a double quote after REPLACE that should have been a comma (,) instead of a double quote ("). Replace that double quote with a comma i.e. from EXECUTE master..sqlbackup '-SQL "RESTORE ... with recovery , DISCONNECT_EXISTING, REPLACE" MOVE .. to EXECUTE master..sqlbackup '-SQL "RESTORE ... with recovery , DISCONNECT_EXISTING, REPLACE, MOVE
You also have a second REPLACE keyword at after all the MOVE keywords, which you can remove. / comments
Hi, there is a syntax error in your RESTORE command that the SQL Backup parser did not detect. Look for the first REPLACE keyword. There is a double quote after REPLACE that should have been a co...
What was the original database name you are now trying to restore using the backup files? In your second script, SQL Backup will only scan the backup files made for the Henrik_UAT database. If the backup files were for a different database, you need to use the SOURCE option e.g. if the files were for a database named Henrik_PROD EXECUTE master..sqlbackup '-SQL "RESTORE DATABASE [Henrik_UAT] FROM DISK = ... SOURCE = [Henrik_PROD] LATEST_ALL WITH REPLACE, PASSWORD = ''<secret>''"
Now SQL Backup will scan all backup files belonging to Henrik_PROD, and restore them to the latest possible state. Your first script (without the LATEST_ALL option) will only restore full database backups. It also works without the SOURCE option because most likely all the files matching the search pattern belonged to the same database. / comments
What was the original database name you are now trying to restore using the backup files? In your second script, SQL Backup will only scan the backup files made for the Henrik_UAT database. If t...
List of updates in 2020 - https://documentation.red-gate.com/sbu10/release-notes-and-other-versions/sql-backup-pro-10-1-release-notes / comments
List of updates in 2020 - https://documentation.red-gate.com/sbu10/release-notes-and-other-versions/sql-backup-pro-10-1-release-notes
Hi, thanks for sending the logs. The May restore averaged 89.555 MB/sec, while the recent restore on November 30 averaged 86.855 MB/sec, which is fairly similar. There is a slight discrepancy for the November restore, where SQL Server reports that the restore took 32870 seconds. The restore started at 2 AM, and only completed at 11:33 AM, when it should have completed at 11:07 AM. It's possible that the 24 extra minutes were due to SQL Server having to initialize the database files, if instant file initialization was not possible. The throughput between backups and restores can be expected to be similar if you were backing up and restoring from the same servers using the same set of disks with the same connectivity. If you copied a file of about 500 MB from the \\lucreserver\DBBackups\MedRisk\ share to the G:\SQLData\ folder on the server you are trying to restore to, what is the reported Windows transfer rate? Thanks. / comments
Hi, thanks for sending the logs.The May restore averaged 89.555 MB/sec, while the recent restore on November 30 averaged 86.855 MB/sec, which is fairly similar. There is a slight discrepancy for t...
Could you please post the contents of the SQL Backup log file for a recent slow backup, and another for a backup that took 4 hours? It may be helpful to compare the 2 logs to see where the delay is occuring. The default folder where the logs are stored is C:\ProgramData\Red Gate\SQL Backup\Log\<instance name>. Thank you. / comments
Could you please post the contents of the SQL Backup log file for a recent slow backup, and another for a backup that took 4 hours? It may be helpful to compare the 2 logs to see where the delay i...
Unfortunately, SQL Backup requires that the user account running the SQL Backup Agent service to have the SQL Server sysadmin server role. / comments
Unfortunately, SQL Backup requires that the user account running the SQL Backup Agent service to have the SQL Server sysadmin server role.
Could you please post the SQL Backup log from the failed SQL Backup backup process? The default folder where the logs are stored is C:\ProgramData\Red Gate\SQL Backup\Log\<instance name>. Thank you. / comments
Could you please post the SQL Backup log from the failed SQL Backup backup process? The default folder where the logs are stored is C:\ProgramData\Red Gate\SQL Backup\Log\<instance name>. Thank you.