SQL Backup

Latest version: 7.2

Notes & articles

Working with the new features in SQL Backup 6

SQL Backup 6 introduces many new features designed to make your backup and restore routines even more efficient and reliable. If you are already familiar with SQL Backup 5, this article will help you get up to speed quickly with some of the new features in SQL Backup 6.

If you have not used SQL Backup before, there are a number of walk-throughs and demo videos available that will introduce you to SQL Backup's main features. For more detailed information, the Learning SQL Backup topics available in the SQL Backup Support Center explain how to use all the features of SQL Backup 6.

This article assumes that you have already installed or upgraded both the SQL Backup graphical user interface (GUI) and the SQL Backup server components. Read more about installing and upgrading.

New features

Network resilience (SQL Backup Pro 6 and later)
Compression level 4 (SQL Backup Pro 6 and later)
Kill existing connections (SQL Backup Pro 6 and later)
Log shipping: prevent destination database initialization (SQL Backup Pro 6 and later)
Enhanced time-line responsiveness
Re-runnable wizards
Manage existing backup files with new delete option
View SQL Backup log files from the SQL Backup GUI
Check for orphaned users during restore (SQL Backup Pro 6 and later)

Network resilience (SQL Backup Pro 6 and later)

SQL Backup Pro 6 introduces network resilience to protect your backup and log shipping jobs from network outages. The network resilience features of SQL Backup Pro 6 and later are turned on by default; you don't need to do anything to start taking advantage of these features immediately.

Network resilience for backups and backup copies

If SQL Backup encounters a read/write error while writing or copying a backup file, it will wait for 30 seconds, then attempt to continue the operation. SQL Backup will wait and retry up to 10 times in total; if the operation has not completed successfully after 10 retries, SQL Backup will mark the operation as failed.

You can use the SQL Backup wizards to change the default network resilience settings (wait for 30 seconds; retry up to 10 times). These settings apply to ad-hoc backups, scheduled backup jobs, and for the backup and copying stages of log shipping.

If you are using the SQL Backup command line or extended stored procedure, you can change the network resilience settings with the new keywords DISKRETRYCOUNT and DISKRETRYINTERVAL. If you omit these keywords, the default values are used automatically. To stop network resilience retries, specify DISKRETRYCOUNT=0.

See The BACKUP command for more information.

Extended network resilience for log shipping

To make your log shipping jobs less susceptible to prolonged network outages, SQL Backup uses an extra level of network resilience whenever you are copying transaction log backup files.

Each transaction log backup file that needs to be copied is placed in a queue (the Log Copy Queue). The copy process for each file in the queue may result in network resilience retries (described above). During a prolonged network outage, the maximum number of retries may be reached, causing the copy process to fail. When this happens, the file remains on the Log Copy Queue. The copy process is then reattempted after two minutes, and then regularly for up to 24 hours.

You can modify the copy schedule for files on the Log Copy Queue by creating registry settings on the server that is performing the backup and copy operations, and then restarting the SQL Backup Agent service.

If you are using the SQL Backup command line or extended stored procedure, you can disable extended network resilience for log shipping by specifying the new USESIMPLECOPY argument. See The BACKUP command for more information.

You cannot disable extended network resilience from the SQL Backup GUI.

Compression level 4 (SQL Backup Pro 6 and later)

SQL Backup Pro 6 adds an extra compression level to those available for backups using SQL Backup 5. The existing compression levels are unchanged; the new compression level 4 provides higher compression ratios than compression level 3, at the expense of more CPU-cycles used. Read more about compression levels.

Compression level 4 will be of benefit whenever you are short of storage space. Additionally, if you are transferring data across the network, compressing it using compression level 4 will reduce the amount of data to be transferred, and hence the time required for the transfer. This may be of particular benefit for log shipping, where you are transferring a sequence of transaction log backup files to a network share at frequent intervals.

You can select compression level 4 from Step 4 of the Backup wizard or Step 5 of the Schedule Backup Jobs wizard.

The Compression Analyzer includes analysis for compression level 4, and is now available from the Tools > Utilities menu in SQL Backup, as well as from the wizard pages listed above.

If you are using the SQL Backup command line or extended stored procedure, you can specify COMPRESSION=4. See The BACKUP Command for more information.

Kill existing connections (SQL Backup Pro 6 and later)

Sometimes it is necessary to kill all existing user connections to a database. For example, if you need to restore a backup over an existing database, or if you need to back up the transaction log tail for a database (that is, using WITH NORECOVERY or STANDBY). If you attempt either operation while there are existing connections to the database, the operation will fail.

SQL Backup Pro 6 and later helps you to avoid failures caused by existing user connections by killing these connections automatically as part of the associated SQL Backup process.

Note that if there are uncommitted transactions associated with an existing connection, these transactions will be rolled back automatically before the connection is killed. The time required to roll back an uncommitted transaction is usually similar to the amount of time that the transaction had been running for prior to rollback.

You can specify the option to kill existing connections to a database from Step 2 of the Restore wizard or Step 1 of the Log Shipping wizard.

If you are using the SQL Backup command line or extended stored procedure, you can kill existing connections to a database by specifying the new keyword DISCONNECT_EXISTING.

See The BACKUP command and The RESTORE command for more information.

Log shipping: prevent destination database initialization (SQL Backup Pro 6 and later)

SQL Backup Pro provides the Log Shipping wizard for you to set up log shipping between two databases.

In SQL Backup Pro 5, initialization of the log shipping destination database is performed automatically. Initialization involves backing up the source database and restoring it to the destination database, which is left in NO RECOVERY or STANDBY mode.

In SQL Backup Pro 6 and later, if your destination database is already in the correct state, you can prevent initialization of the destination database by clearing the check box in Step 1 of the Log Shipping wizard.

Enhanced timeline responsiveness

In SQL Backup 6, the timeline display is very similar to the time line in SQL Backup 5. However, changes to the way that SQL Backup collects and refreshes the data mean that the timeline in SQL Backup 6 refreshes more quickly, and is more responsive when you have added many instances and databases.

The timeline display is now refreshed every minute, starting with the selected SQL Server instance, then other instances that are visible. While the connection to the instance is being refreshed, is displayed. You can continue to interact with the timeline while a connection is being refreshed.

Red shading has been added to show that the connection to a SQL Server instance has failed. Green shading shows that data is being collected for that particular section of the timeline:

Re-runnable wizards

In SQL Backup 6, the step-by-step wizards (Back Up, Schedule backup jobs, Restore, and Log Shipping) all include a Retry button on the final progress dialog box. Retry is available if an activity fails to complete:

LogShippingJobRetry

When you click Retry, you are returned to the final wizard page, and have the option to step back and adjust any of the wizard settings before attempting to run the activity again.

Manage existing backup files with new delete option

SQL Backup 6 includes a new option to help you manage existing backup files. In SQL Backup 6, you can specify the number of recent backup files that you want to keep; SQL Backup will delete older files.

Additionally, you can now use the SQL Backup GUI to specify delete options for backup files written to network locations.

The options for managing existing backup files are available from Step 3 of the Back Up wizard or Step 4 of the Schedule Backup Jobs wizard.

If you are using the SQL Backup command line or extended stored procedure, you can delete files based on the number of recent files that you want to keep, by using the existing keywords ERASEFILES, ERASEFILES_ATSTART, and ERASEFILES_REMOTE. These keywords now accept values of the form keep{b}, where b indicates the number of recent files to keep. For example, ERASEFILES_REMOTE=5b ensures the latest 5 remote files are kept; older remote files are deleted. The files are deleted only if the backup process completes successfully.

See The BACKUP command and The RESTORE command for more information.

View SQL Backup log files from the SQL Backup GUI

You can now more easily view the contents of SQL Backup log files for specific activities.

Right-click a completed activity on the time line, or an item in the Activity History tab or Log Copy Queue tab, and click Show Log to display the contents of the log file:

activitylog

You can also show the log file contents from the Properties window for an activity, by clicking Show Log.

Check for orphaned users during restore (SQL Backup Pro 6 and later)

If you are restoring a database to a different SQL Server instance from the backup source, it is possible that some of the restored database user accounts will not have an associated server login on that instance. These database user accounts are known as orphaned users, and will be unable to provide access to the database unless you create their associated logins.

SQL Backup Pro 6 can run a check for orphaned users once a restore has completed. If any orphaned users are found, a warning is included in the SQL Backup log file along with a list of the orphaned users.

SQL Backup does not fix orphaned users automatically. If orphaned users are reported, you should consider creating the required logins on the SQL Server instance that you are restoring to.

For more information about database user accounts, logins, and fixing orphaned users, refer to your SQL Server documentation.

You can specify the option to check for orphaned users from step 3 of the Restore wizard.

If you are using the SQL Backup command line or extended stored procedure, you can check for orphaned users when restoring a database by specifying the new keyword ORPHAN_CHECK.

See The RESTORE command for more information.

Was this article helpful?

Search support