<quote>Can I use the file location tags in the "Copy Backup To Network Location" option?</quote>
Yes you can. E.g.
In this example, g:\ is a local folder. This command will back up all your databases to this local folder, in subfolders named after the database, then by backup type. At most, only 2 backup sets will be retained in each folder (ERASEFILES_SECONDARY = 2b). It will also copy the backup file to a network share, in subfolders named after the database, backup type and current year and month. Only 14 backup sets will be retained in each of those folders (ERASEFILES_SECONDARY = 14b).
Why create subfolders named after the database name and backup type? This helps to reduce the number of files in any one of those folders. Whenever you use any of the ERASEFILES_* options, SQL Backup needs to determine which backup files to keep, and which to delete, every time a backup completes. If your instance contains hundreds of database, and you have transaction logs running every 10 minutes, the number of files will grow rapidly. If you only backed up to a folder named 'g:\backups\', SQL Backup will need to process thousands of files every time. This would not be an issue if you only had a few databases backed up.
Likewise for files copied to the network share. Again, if you have a lot of backup files stored remotely, it's advisable to organise the files by database name and backup type for the reasons above.
One cavest when using folders named after the current year and month is that when SQL Backup creates a new folder based on those attributes, it won't look into the previously created folders to delete the older files. E.g. using the example above, SQL Backup may copy today's backup files into
\\sqlfileserver\backups\AdventureWorks\LOG\2013 02\...
We can expect to find 14 backup sets in that folder at any one time, since we're using the ERASEFILES_SECONDARY = 14b option. Tomorrow, when SQL Backup starts storing files in
\\sqlfileserver\backups\AdventureWorks\LOG\2013 03\...
it won't look in the \2013 02\ subfolder to erase the older files. By April, you will have the last 14 backup sets in the February folder, and the last 14 backup sets in the March folder. Which is pretty useless as they won't form a complete recovery chain.
Yes you can. E.g.
| Code: |
| EXEC master..sqlbackup '-sql "BACKUP DATABASES [*] TO DISK = [g:\backups\<DATABASE>\<TYPE>\AUTO.sqb] WITH COPYTO = [\\sqlfileserver\backups\<DATABASE>\<TYPE>\<DATETIME yyyy mm>\] WITH ERASEFILES_PRIMARY = 2b, ERASEFILES_SECONDARY = 14b"' |
In this example, g:\ is a local folder. This command will back up all your databases to this local folder, in subfolders named after the database, then by backup type. At most, only 2 backup sets will be retained in each folder (ERASEFILES_SECONDARY = 2b). It will also copy the backup file to a network share, in subfolders named after the database, backup type and current year and month. Only 14 backup sets will be retained in each of those folders (ERASEFILES_SECONDARY = 14b).
Why create subfolders named after the database name and backup type? This helps to reduce the number of files in any one of those folders. Whenever you use any of the ERASEFILES_* options, SQL Backup needs to determine which backup files to keep, and which to delete, every time a backup completes. If your instance contains hundreds of database, and you have transaction logs running every 10 minutes, the number of files will grow rapidly. If you only backed up to a folder named 'g:\backups\', SQL Backup will need to process thousands of files every time. This would not be an issue if you only had a few databases backed up.
Likewise for files copied to the network share. Again, if you have a lot of backup files stored remotely, it's advisable to organise the files by database name and backup type for the reasons above.
One cavest when using folders named after the current year and month is that when SQL Backup creates a new folder based on those attributes, it won't look into the previously created folders to delete the older files. E.g. using the example above, SQL Backup may copy today's backup files into
\\sqlfileserver\backups\AdventureWorks\LOG\2013 02\...
We can expect to find 14 backup sets in that folder at any one time, since we're using the ERASEFILES_SECONDARY = 14b option. Tomorrow, when SQL Backup starts storing files in
\\sqlfileserver\backups\AdventureWorks\LOG\2013 03\...
it won't look in the \2013 02\ subfolder to erase the older files. By April, you will have the last 14 backup sets in the February folder, and the last 14 backup sets in the March folder. Which is pretty useless as they won't form a complete recovery chain.