MS SQL-Database Backup Types and Methodology
These backup types are available in sql server 2008:
Resource Database :The physical file names of the Resource database are mssqlsystemresource.mdf and mssqlsystemresource.ldf. These files are located in <drive>:\Program Files\Microsoft SQL Server\MSSQL11.<instance_name>\MSSQL\Binn\. Each instance of SQL Server has one and only one associated mssqlsystemresource.mdf file, and instances do not share this file.
To determine the version number of the Resource database, use: SELECT SERVERPROPERTY('ResourceVersion');
To determine when the Resource database was last updated, use: SELECT SERVERPROPERTY('ResourceLastUpdateDateTime');
To access SQL definitions of system objects, use the OBJECT_DEFINITION function SELECT OBJECT_DEFINITION(OBJECT_ID('sys.objects'));
What is snapshot in 2005
Database Snapshots are a new Enterprise Edition-only tool, introduced in SQL 2005, that provide a read-only, "virtual" copy of a database, at a given point in time.
Snapshots are read only static views of the database
sp_helpdb 'AdventureWorks2012'
name FILENAME
AdventureWorks2012_Data C:\AdventureWorks2012_Data.mdf
AdventureWorks2012_Log C:\AdventureWorks2012_log.ldf
---------------------------------------------------------------------------------------------------------------
Create a snapshot of the database.
CREATE DATABASE AdventureWorks_dbss1800 ON
( NAME = AdventureWorks2012_Data, FILENAME =
'C:\Program Files\Microsoft SQL Server\SQLSERVER2012\MSSQL11.SQLSERVER12\MSSQL\DATA\AdventureWorks_data_1800.ss' )
AS SNAPSHOT OF AdventureWorks2012;
GO
----------------------------------------------------------------------------------------------------------------
sp_helpdb 'AdventureWorks_dbss1800'
name FILENAME
AdventureWorks2012_Data C:\AdventureWorks2012_Data.mdf
AdventureWorks2012_Log C:\AdventureWorks2012_log.ldf
MSDB database be moved
Yes! The MSDB database files can be moved. The are 2 methods to move the MSDB database files. One is a more common method, especially during a new install with limited users or uptime requirements. The other lets the SQL Server instance stay up and interrupts only the MSDB-dependent parts of the operation such as the SQL Server Agent.
Option 1
This is the more common method that is generally suggested
Step 1- Inform SQL Server that during the next startup of the service the MSDB database data and/or log file(s) will be somewhere else.
During this step it will allow the file name to be changed, but it is not advised to change the physical file name or extension.
The following code will change the expected location of the MSDB database data and log files respectively from wherever they currently are to the root C drive. It assumes the default logical names.
ALTER DATABASE [MSDB] MODIFY FILE ( NAME = MSDBData , FILENAME = 'C:\MSDBData.mdf' );
ALTER DATABASE [MSDB] MODIFY FILE ( NAME = MSDBLog, FILENAME = 'C:\MSDBLog.ldf' );
Executing these commands will give a very clear output message.
The file "MSDBData" has been modified in the system catalog. The new path will be used the next time the database is started.
The file "MSDBLog" has been modified in the system catalog. The new path will be used the next time the database is started.
Step 2 -Now that SQL Server has been informed of the new location(s), stop the SQL Server and SQL Server Agent services so that it will release its lock on those 2 (or more) MSDB database files.
Step 3 -Move the file(s) to the intended location(s) that were given to SQL Server in step 1.
Step 4 -Start the SQL Server service.
SQL Server should start right up. Immediately check MSDB in SSMS. Does it look like the screenshot from the very beginning of this tutorial with the words "(Recovery Pending)" at the end? If so, there is a problem with the file location of the MSDB files. Perhaps they aren’t in the same place the catalog thinks they are or maybe they are in the right place, but the service account can’t see them there due to a permission issue. Sometimes the Event Viewer, if using Windows, offers more details as to why some databases don’t come online and should be consulted. In any case, work to resolve that issue and consider putting the files back, if necessary, to get the instance up and running again.
Option 2
Start by stopping the SQL Server Agent service and kill any other processes that might be using MSDB. Then, simply back up the MSDB database and immediately restore MSDB with the REPLACE option and use the MOVE keyword to select a new location for any files.
BACKUP DATABASE [msdb] TO DISK = N'C:\backups\MSDB.bak';
GO
RESTORE DATABASE [msdb] FROM DISK = N'C:\backups\MSDB.bak'
WITH REPLACE,
MOVE N'MSDBData' TO N'C:\Backups\MSDBData_NEW.mdf',
MOVE N'MSDBLog' TO N'C:\Backups\MSDBLog_NEW.ldf';
GO
Once the restore finishes successfully, restart the SQL Server Agent.
Moving the master Database
To move the master database, follow these steps.
From the Start menu, point to All Programs, point to Microsoft SQL Server, point to Configuration Tools, and then click SQL Server Configuration Manager.
In the SQL Server Services node, right-click the instance of SQL Server (for example, SQL Server (MSSQLSERVER)) and choose Properties.
In the SQL Server (instance_name) Properties dialog box, click the Startup Parameters tab.
In the Existing parameters box, select the -d parameter. In the Specify a startup parameter box, change the parameter to the new path of the master data file. Click Update to save the change.
In the Existing parameters box, select the -l parameter. In the Specify a startup parameter box, change the parameter to the new path of the master log file. Click Update to save the change.
The parameter value for the data file must follow the -d parameter and the value for the log file must follow the -l parameter. The following example shows the parameter values for the default location of the master data file.
-dC:\Program Files\Microsoft SQL Server\MSSQL<version>.MSSQLSERVER\MSSQL\DATA\master.mdf
-lC:\Program Files\Microsoft SQL Server\MSSQL<version>.MSSQLSERVER\MSSQL\DATA\mastlog.ldf
If the planned relocation for the master data file is E:\SQLData, the parameter values would be changed as follows:
-dE:\SQLData\master.mdf
-lE:\SQLData\mastlog.ldfClick OK to save the changes permanently and close the SQL Server (instance_name) Properties dialog box.
Stop the instance of SQL Server by right-clicking the instance name and choosing Stop.
Move the master.mdf and mastlog.ldf files to the new location.
Restart the instance of SQL Server.
Verify the file change for the master database by running the following query.
SELECT name, physical_name AS CurrentLocation, state_desc FROM sys.master_files WHERE database_id = DB_ID('master');
At this point SQL Server should run normally. However Microsoft recommends also adjusting the registry entry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\instance_ID\Setup, where instance_ID is like MSSQL13.MSSQLSERVER. In that hive, change the SQLDataRoot value to the new path. Failure to update the registry can cause patching and upgrading to fail.
Piecemeal Restores
In SQL Server 2005, databases that contain multiple filegroups can be restored and recovered in stages through a process known as piecemeal restore. Piecemeal restore involves a series of restore sequences, starting with the primary filegroup and, in some cases, one of more secondary filegroups. After the restore sequence is completed, recovered files, if they are valid and consistent with the database, can be brought online directly.
In SQL Server 2012 piecemeal restore sequence restores and recovers a database in stages at the filegroup level, beginning with the primary and all read-write, secondary filegroups.
Every piecemeal restore starts with an initial restore sequence called the partial-restore sequenc
Recovery point objective - Recovery time objective strategy
The RPO represents the point in time, prior to such an event or incident, to which lost data can be recovered (given the most recent backup copy of the data). It is the maximum tolerable period in which data might be lost from an IT service due to a major inciden
The recovery time objective (RTO) is a period of time within which business and / or technology capabilities must be restored following an unplanned event or disaster.
Specific operational goals of implementing recovery point objectives / recovery time objectives
As such RPO and RTO are key metrics for measuring recovery time and data characteristics. Other supplementary metrics include:
Recovery Time Granularity (RTG) determines the time spacing between recovery points; whereas RPO is the last recovery point prior to a failure, RTG defines recovery point selection options prior to that recovery point.
Recovery Object Granularity (ROG) expresses the level of objects that a recovery solution is capable of recovering. For instance, object granularity may be a storage volume, a file system, a database table, a database row / column / field, a transaction, a mailbox, an email message, etc.
Recovery Event Granularity (REG) measures the ability of a recovery solution to track events and to recover an application or data to a specific event.
Recovery Consistency Characteristics (RCC) measures the usability of recovered data by the associated application.
Recovery Location Scope (RLS) defines where the protected data must be stored when recovery takes place (i.e., locally, remotely, on which media / storage tier).
Recovery Service Scalability (RSS) measures the number of applications or data sets the recovery solution handles, and the maximum size of the data it can store.
The Maintenance Point Objective (MPO) describes the maximum allowable window for the performing scheduled system maintenance
Restore from Snapshot
USE master RESTORE DATABASE AdventureWorks2012 FROM DATABASE_SNAPSHOT = 'AdventureWorks_dbss1800'Restore Databases Syntax
Restoring a full database backup RESTORE DATABASE Adventureworks FROM DISK = 'C:\Backup\AdventureWorks.bak';if we wanted to restore the second file in the group, the COPY_ONLY backup
RESTORE DATABASE AdventureWorks FROM DISK = 'C:\Backups\Adventureworks.bak' WITH FILE = 2, REPLACE;This can then be used to identify the appropriate logical names in order to generate this script:
RESTORE DATABASE AdventureWorks_2 FROM DISK = 'C:\Backups\Adventureworks.bak' WITH FILE = 2, MOVE 'AdventureWorks_Data' TO 'C:\backups\aw2_data.mdf', MOVE 'AdventureWorks_Log' TO 'C:\backups\aw2_log.ldf';Restoring a differential backup
The last method is to apply the differential backup. This requires two steps. First, we'll restore the database, but with a twist and then we'll apply the differential backup:
RESTORE DATABASE AdventureWorks FROM DISK = 'C:\Backups\Adventureworks.bak' WITH FILE = 1 , NORECOVERY, REPLACE; RESTORE DATABASE AdventureWorks FROM DISK = 'C:\Backups\AdventureWorks.bak'WITH FILE = 3;Restoring SQL Server databases to a point in time
Restoring logs is not much more difficult than the differential database restore that we just completed. There's just quite a bit more involved in restoring to a moment in time. Assuming you're backing up your logs to a single file or device:
RESTORE HEADERONLY FROM DISK = 'C:\Backups\Adventureworks_log.bak';
Otherwise, you simply go and get the file names you need. First run the database restore, taking care to leave it in a non-recovered state. Follow this up with a series of log restores to a point in time.
RESTORE DATABASE AdventureWorks FROM DISK = 'C:\Backups\Adventureworks.bak' WITH FILE = 1, NORECOVERY, REPLACE, STOPAT = 'Oct 23, 2006 14:30:29.000'; RESTORE LOG AdventureWorks FROM DISK = 'C:\Backups\Adventureworks_log.bak' WITH FILE = 1, NORECOVERY, STOPAT = 'Oct 23, 2006 14:30:29.000'; RESTORE LOG AdventureWorks FROM DISK = 'C:\Backups\Adventureworks_log.bak' WITH FILE = 2, NORECOVERY, STOPAT = 'Oct 23, 2006 14:30:29.000'; RESTORE LOG AdventureWorks FROM DISK = 'C:\Backups\Adventureworks_log.bak' WITH FILE = 3, NORECOVERY, STOPAT = 'Oct 23, 2006 14:30:29.000'; RESTORE LOG AdventureWorks FROM DISK = 'C:\Backups\Adventureworks_log.bak' WITH FILE = 4, STOPAT = 'Oct 23, 2006 14:30:29.000'; RESTORE DATABASE Adventureworks WITH RECOVERY;How to Verify File Integrity Of Backups
Using VERIFYONLY Verify database backup integrity and checking backups are corrupted or not
RESTORE VERIFYONLY FROM DISK ='D:\Backup_20110517.bak'
Using HEADERONLY with Restore command we have details for database backup files and verify FULL, Differential and Transactional log backups
RESTORE HEADERONLY FROM DISK ='D:\Backup_20110517.bak'
Using HEADERONLY containing a list of the database and log files contained in the backup set
RESTORE FILELISTONLY FROM DISK ='D:\Backup_20110517.bak'
The RESTORE LABELONLY option allows you to see the backup media information for the backup device
RESTORE LABELONLY FROM DISK = 'C:\AdventureWorks.BAK'
Database Backup Syntax
Copy-only backups
BACKUP DATABASE AdventureWorks TO DISK = 'C:\Backups\AdventureWorks.bak' WITH COPY_ONLY;
Differential backups
BACKUP DATABASE AdventureWorks TO DISK = 'C:\backups\AdventureWorks.bak' WITH DIFFERENTIAL; Now, if we had to restore this database, we'd first go to the last full backup, restore that, and then restore the differential backups in order (more on that later).
BACKUP DATABASE Adventureworks
TO DISK = 'C:\backups\AdventureWorks.bak' WITH INIT;Log backups
BACKUP LOG Adventureworks TO DISK = 'C:\backups\AdventureWorks_Log.bak';If you have your database set to FULL Recovery, you need to run log backups. Sometimes, people forget and the transaction log grows to the point that it fills up the disk drive. In this case, you can run:
BACKUP LOG Adventureworks WITH NO_LOG;
Tail log Back: You can back up the transaction log even though the data files are no longer available, using the NO_TRUNCATE option e.g.
BACKUP LOG AdventureWorksTO DISK = 'G:\Backups\AdventureWorks_log_tail.bak' WITH NO_TRUNCATE
For SQL Safe
Backup Database
exec master..xp_ss_backup @database = 'DatabaseName', @filename = 'D:\Backup\DatabaseName_FUll_Date.safe', @init = 1, @compressionlevel = 'isize', @threads = 3;To verify backup file
xp_ss_listfiles @filename='D:\DB_Backup\DatabaseName_FUll_Date.safe'
Restore Database
exec master..xp_ss_restore
@database = 'Database_Name',
@filename='D:\DB_Backup\DatabaseName_FUll_Date.safe',
@withmove = 'DB_MDF_LOgicalName D:\MS SQL Server\Data\DBName.mdf'
,@withmove = 'DB_LDF_logicalName_Log F:\MS SQL Server\Logs\DBName.ldf'
,@withmove = 'DB_LDF_logicalName_Log1 F:\MS SQL Server\Logs\DBName1.ldf'
,@withmove = 'DB_Catalog_FT E:\MS SQL Server\FText\DB_Catalog_Production_FT'
,@replace = 1
Attached Related Documents Below :
System Database's Information: