Backup and recovery concepts Recovery factors
You may wish to optimize on backup volume and recovery speed by placing some of your data into read-only filegroups. See “Reducing backup size and time by using read-only filegroups (SQL Server 2005)” on page 54.
The filegroup and file backup also carries the advantage on restore that, in case of disk failure, it would be possible to recover just the failed unit without restoring the entire database.
In order to use filegroup and file backups you must maintain backups of the transaction log. For example, to perform a full database restore using filegroups and files, you would be required to restore all of the constituent filegroups and files in addition to all of the transaction log segments starting from the point at which the first component backup was taken up until a point in time following the last component backup.
During the restore process, a database goes into “loading mode” until the restore command is executed against the database with the “recovery” option. Prior to placing the database into recovery mode all of the restore commands would be executed using the “Not recovered” option. This way it is possible to continue to stage additional restore statements to bring the database up to the desired state. The database becomes usable again after the last restore statement has been applied the “Recovered” option.
You can choose the desired recovery option when performing restores. See online help for the Restore Microsoft SQL Server Objects dialog box.
NetBackup for SQL Server keeps track of the backups you have performed and when you performed them.
You can display the backup history by opening the Restore Microsoft SQL Server Objects dialog box.
This dialog box depicts all of the SQL Server backup images within the parameters that you specify. The images are displayed in tree-form based on the following backup types: