Network resilience

Prev Page Next Page
Recovery models
Main backup types
Backing up the database files by copying
The transaction log
Transaction log restore sequence
Log sequence numbers
Truncating and shrinking the transaction log
Backing up the tail
Inside the transaction log
So, what's in a backup file?
Test: A full backup does not contain deleted data
Verifying backup files
Verifying backup files on a budget
Cumulative backups
Recovering individual tables
Backup and restore history details
Backup reads and writes
Speeding up backups
Backup speed details
Speeding up restores
Restore state affects speed too
Backup and restore rights
Log shipping
Log shipping in SQL Server 2000
Setting up log shipping using Enterprise Manager
Checking the set up
Log shipping in SQL Server 2005
Setting up log shipping using Management Studio
Checking the set up
Log shipping status report
Log shipping in SQL Backup
Using the CopyTool utility
3rd party backup applications
VDI versions
VDI errors
SQL Backup - beyond compression
Restoring a chain of transaction log backups
Restoring to the latest possible state
Backing up multiple databases
Backup retention
Making a copy of the backup file
Backup file naming conventions
Restoring the latest backup set
Network resilience
Integrated database verification
Database file relocation
Improved backup retention
High-availability group support
Common SQL Backup issues
Installation checklist
Setting up rights
Configuring service rights
Backup data
Hanging issues
Common backup and restore errors
Error 3201 - when performing a backup to a network share
Full database backup file is larger than database size
Error 3205 - Too many backup devices specified for backup or restore
Error 4305 - an earlier transaction log backup is required
Bringing a database that is in recovery or read-only mode online
Using bulk-logged recovery model but transaction log backup is still large
Error 14274 - unable to delete SQL Server Agent job
Error messages when restoring from different versions of SQL Server.
vdi error codes
Restore speed details
Help, my transaction log file is huge!
Mirror or log ship

# available only in SQL Backup 6 Professional and newer

With the availability of the COPYTO option in SQL Backup, users could easily copy their backup files to one or more network shares, in accordance with the best practice of not having all your backup files on one box.  However, the copy process could fail due to a temporary network outage.  The impact of this outage is most disruptive on log shipping setups, which causes a break in the chain of log backups that the secondary server can restore.

To overcome this, SQL Backup will make multiple attempts to copy the file to the network share(s) when it encounters a network glitch.  Furthermore, it doesn't copy the entire file from the beginning.  Instead, it will resume the copying from the point of the last successful write.

This feature is easily configurable using the DISKRETRYINTERVAL and DISKRETRYCOUNT options.  For example, if you want SQL Backup to reattempt the copy 5 times in between intervals of 60 seconds, you would run the following:

EXEC master..sqlbackup '-sql "BACKUP DATABASE AdventureWorks TO DISK = [g:\backups\<AUTO>] WITH COPYTO = [\\backupstore\AdventureWorks\], DISKRETRYINTERVAL = 60, DISKRETRYCOUNT = 5" '


By default, SQL Backup uses a DISKRETRYINTERVAL value of 30 seconds, and a DISKRETRYVALUE of 10.

This network resilience feature is also available for primary backups i.e. if you back up directly to a network share and there is a network glitch, SQL Backup will make multiple attempts to complete the disk write.  While backing up directly to a network share is not something we recommend doing, we undersand that sometimes circumstances dictate the need to do this, and that's what we have the network resilience feature for.

Document history
11/4/2010    Initial release.    
Copyright 2008 - 2021 Yohz Ventures Sdn Bhd. All rights reserved.
All product and company names are trademarks or registered trademarks of their respective owners.