ApexSQL Restore can attach native or natively compressed backups and backup sets created in SQL Server 2000 and above to any edition of SQL Server 2005 and above, including full and differential database backups as well as transaction log backups
As such, ApexSQL Restore is very useful, among others, in the following scenarios:
- To recover from inadvertent or malicious changes
Attach the backup set containing the original data or objects. This is faster than a full physical restore, takes up less space but provides the same access to objects and data in questions. Once the backup is attached, simply copy the affected data or objects to the original database while ensuring that the backup file itself will remain untouched - To verify backups
Mount your backup as a live database to fully confirm the backup integrity including the integrity of the objects and the data stored in the backup file itself. Virtual databases behave just like regular ones, so it’s even possible to run DBCC CHECKDB to verify their validity - To performance tune a production databases
Attach a backup of a large production database to performance tune it without introducing any additional overhead and degrading its performance. All changes made on the virtual database will have the same effect when moved back into production - To provide concurrent database access in test and development environments
Eliminate the need for each developer and tester to have a local copy of a database by providing them access to the attached backup. This preserves not only the time and space otherwise wasted on a full restore – it ensure that each team member will have the access to the same database as although read and write operations are fully supported, the backup itself will be unaffected by any made changes - In a continuous integration environment
Simply reattach the virtual databases listed in History and deploy the latest upgrade SQL scripts against them instead of performing a full restore of the test databases each time a new version needs to be tested or rolled out - To speed up reporting
Attach a full backup of a busy production database to be used as a reporting data source thus avoiding any performance impact on the production database while cutting down on the time the disk space needed for a full restore
