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.

SELECT name, physical_name AS CurrentLocation, state_desc  FROM sys.master_files  WHERE database_id = DB_ID('master');   



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


              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: