MS SQL Backups explained by a DBA

MS SQL Backups explained by a DBA
This Excerpt will help you understand and implement the
following concepts:
1. What are Backups
2. Preparing a Backup plan on paper
3. Sample Backup Plan
4. Planning a database Backup
5. Creating a Backup user with T-SQL
6. Modifying a Backup user with SSMS
7. Introduction to Recovery Models
8. Introduction to Backup types
9. Creating the Backup script with T-SQL
10. Explaining the Backup script options
11. Pros and Cons of the script used
12. Continuous improvement process of the script
13. Automating the Backup process
14. Auditing the Backup results
15. Personal advise to other DBA professionals
.:: MS SQL Backups explained by a DBA – Copyright © 2019 by Wally M. Pons and Datagrupo ::.

About this excerpt and the author
• This Excerpt is the result of accumulated experiences, long readings
and well gained real life knowledge throughout my IT/DBA career. It
covers what I consider to be the most relevant material to face the
case scenarios that you’ll probably encounter along your path as a
DBA, which as you may know it’s something you become either by
accident, choice or the combination of the both.
• The author’s name of this excerpt is Wally M. Pons, an IT
professional with over 20 years of experience. For questions or
comments you may contact him as follows:
 Twitter: @datagrupo / @wallypons
 Web: Https://www.datagrupo.com
 Email: wpons@datagrupo.com

What are Backups
• There are many ways we can define this title, the first and most
simple one is “The process of copying information into an archive file
of computer so that it can be used to be restored to the original after
a data loss event”.
• Beyond this basic explanation, in the DBA realm a Backup can be
one of the following:
1. The (if not the most) important task of the DBA
2. Your first line of defense, organizationally and personally
3. 50% or more of all your responsibilities
4. The fine line between good or bad reputation

Preparing a Backup Plan on paper
• Also known as a “Disaster Recovery Plan”, the Backup Plan
document is part of the good practices documentation from a
corporate point of view, thus it must be written with a detailed
content and by responsible parties without any ambiguities in its
entirety.
• The organizational content of the document may vary in structure
and order depending on the size and needs of the organization, this
means that the process of evaluating such content criteria may
involve more than just a DBA point of view, as a result, it should not
be taken lightly.
• A sample guideline as of the contents layout is included on the next
slide, please note that it needs to be expanded in detail and it may
be different from one organization to another.

Sample Backup Plan
1. Document header information
1. Creation date
2. Author and responsible employees
3. Commentators and revisions
4. Version numbering
2. Backup scheduling definition and intervals
1. Daily
2. Weekly
3. Monthly
3. Backup type considerations based on the schedule and date
1. Execute 1 Full Backup Monthly
2. Execute 2 Differentials Backups per day
3. Execute 6 Log Backups Between Differentials
4. Process security
1. Backup encryption levels (AES 128, 192, 256 or better)
2. Custodian and responsible of the resultant files
5. Media type and storage
1. Tape or Disk
2. On site storage (security vault)
3. Off site storage (third party services, other considerations)
4. Cloud storage with specified costs
6. Backup reports
1. These can be automatically generated by MS SQL Server and alternatively delivered by email
2. Information can be retrieved from the msdb database using T-SQL scripts

Planning a database Backup
• Although there are several ways to perform a MS SQL Backup, it is
always a best practice to do this task using a T-SQL script, this is a
preferred approach mostly because of the parameterization control
that gives you over the task in comparison to a built-in wizard.
• Before we can make a T-SQL Backup on any database, the SQL or
Windows user account must have the appropriate privileges, unless
is a sysadmin account in which case you don’t have to worry about
permissions.
• Please be aware that even though using a sysadmin account takes
away the hassle of assigning permissions to an account/database, it
is is something you must avoid for security reasons.

Creating a Backup user with T-SQL
• The following script creates a user whose sole purpose is to make
backups:
• The above script is divided in three portions, the first one creates the
user and assigns the “dbcreator” role, the second portion assigns
the user to the “SQLAgentOperatorRole” on the msdb database and
the last portion creates the user on “StackOverflow50GB” database
with two roles: “db_backupoperator” and “db_denydatareader”.

Modifying a Backup user with SSMS
• Once your user is created you may modify it using these steps on
SSMS:
1. Login to MS SQL Server with a privileged account (Admin rights)
2. Open object explorer by pressing the “F8” key (if not loaded already)
3. Expand the security folder (normally below the database folder)
4. Expand the logins folder and locate the “BackupJobDemo” user
5. Right-click the user and select the “Properties” option as shown below

Introduction to Recovery Models
• All databases have a recovery model when they are created, even if
you don’t specify one it will use the default from the “model”
database (this is a system database). An advantage of Recovery
Models is that they may be altered as needed, although this is not a
good practice, specially in production environments.
• There are three Recovery Models available:
– Full
• This is the most complete model available, it allows recoverability (in case of any incident) of
all your data for any given point in time if all your backup files are within reach.
– Bulk-Logged
• This recovery model is best used for bulk operations such as inserts, updates, deletions, index
creation and similar operations. It is like the Full recovery model, except that it doesn’t log the
aforementioned transactions.
– Simple
• This recovery model is the simplest one, contrary to the Full and Bulk-Logged it lacks the
ability to recover data from the database log file, you may still recover data only if you made a
recent Backup of the database, also it is not recommended to use this recovery model for high
availability scenarios.

Introduction to Backup types
• There are several Backup types that can (or not) be performed to a
database depending on its type or recovery model, below is a list of
the most common backup types and the databases that support it.
– Full: This is the most common type of Backup, it makes a complete copy of the
database and can be done on any database.
– Differential: This type of Backup is tied to the previous Full Backup because as
it stores any changes done after it. Differential backups are not supported on the
“master” system database.
– Transaction Log: This Backup can only be done on databases with the “Full” or
“Bulk-Logged” Recovery Models. It also helps you when doing a specific point-in-
time recovery of your data and any uncommitted transactions on the log.
– Copy Only: This type of Backup works exactly as a Full Backup with the
exception of not marking it on the “msdb” database as a Full, therefore the log
sequence number is not renewed and you can still keep on making differential
Backups tied to your last Full Backup.

Introduction to Backup types
• A special note about Backups and databases is that there is one
system database that you can’t Backup, that database is the
TempDB.
• The reason for this is that “TempDB” is only used to store server-
wide temporary objects and transactions. Besides, everything you
put in it will be deleted upon a SQL service restart, and if you try to
do a Backup then you get a “Message 3013 error” reading:
– Backup and restore operations are not allowed on database tempdb.
• As a knowledge-worthy note, there is also another system database
called “Resource Database” that you cannot Backup using SQL
Server, though you may accomplish this by making a file or disk
based Backup, for more information you may click the link below:
https://docs.microsoft.com/en-us/sql/relational-databases/databases/resource-
database?view=sql-server-2017

Creating the Backup script with T-SQL
• Here is a T-SQL script for a Full Backup, it is an extremely simple
code which will be explained on the next slide.

Explaining the Backup script options (1 of 2)
• The Backup script is composed by parameters and options which
define how the process will be performed, here is a detailed
explanation of our previous script:
– BACKUP: This is the first command you must issue.
– DATABASE: This parameter specifies that we’re making a backup to a
database, if we need to make a transaction log backup then we specify LOG
instead.
– [StackOverflow50GB]: This is the name of the database.
– TO DISK = N’’: This portion specifies the path and file name of the backup, you
can also specify a TAPE or URL. Please note that beyond this point all options
are preceded by the With keyword and are separated by commas.
– Compression: Starting with MS SQL Server 2008 R2 you may compress your
backups in size, this was achievable only with third party software solutions or
manually compressing the resultant file(s) with the compression software of your
choice.

Explaining the Backup script options (2 of 2)
– Format: This option writes the “Media Header Information” of the Backup file,
which is stored on the metadata and can be retrieved using the RESTORE
HEADERONLY command. As seen here it will only write this information once on
the Backup file. Its counterpart is NoFormat, which allows this information to be
written multiple times.
– Init: This option tells MS SQL Server to not overwrite a file, which is usefull to
maintain the uniqueness of a Backup file itself. Its counterpart is NoInit and
when used along with NoFormat you may create a single file with several
Backups in it.
– Stats: This option represents the Backup progress in percent, it is an integer
value, which means you cannot use fractions, only whole numbers from 1 to 100
can be set with this option. In our sample Backup we used the value 10 which
represents a 10% of the progress.
• At the bottom you are displayed with the results of the Backup,
along with the files processed and the time taken in seconds.

Pros and Cons of the script used
• The script we just used has some interesting characteristics which
we will classify as Pros and Cons:
– Pros:
• Is very simple, single-lined and gets the job done quickly
• Doesn’t require an extensive knowledge of the T-SQL language
• Can be modified with little effort from the user
• You can execute it multiple times, as long as you have control over the file
• Can be used on a SQL job scheduling scheme, with the same conditions as above
– Cons:
• It only does Full Backups, at least as is
• It also lacks other options that might help document it better
• Does not add a timestamp to the files and uses the same name for the file
• You must be careful when executing it multiple times
• Use it on a SQL job scheduling scheme at your own risk
• As with most things in life, the T-SQL Backup script requires a
continuous improvement process, which is what we’ll see on our
next slide.

Continuous improvement process of the script
• The Backup script can be enhanced in an exponential way to
accommodate the needs of the DBA/Management. We’ll start by
explaining from minor changes to major ones as follows:
a) Once you have a Full Backup you can make Differentials
– After making a Full Backup and in order to just keep the difference of changes
occurred thereafter, you make Differential Backups. This is accomplished by
adding the “Differential” option to our script so it will look as follows:

b) Add a name to your file metadata
– You may add a name to your Backup set metadata, this option is usually for the
name of the backup including a date or specific detail. It has a limit of 128
characters in length:
c) Add a description to your file metadata
– You may also add a longer text, known as a free-form text, in which you may
include a much longer text of 255 characters in length:
d) Create a COPY_ONLY Backup
– If all you want is a full copy of the database without making a Full Backup then
you add the COPY_ONLY option:

e) Create a LOG Backup
– This is applicable only to databases with the FULL and BULK-LOGGED
Recovery Models, it serves the purpose of regularly cleaning transactions from
the Log file of the database thus preventing it from growing beyond its size and
also helps you make point-in-time restores of the database:
f) Create a Timestamped Backup (applies same previous rules)
– In the following script we take care of the final filename as it automatically adds
the server name and timestamps the file with the execution date and time:

Automating the Backup process
• A very common task amongst DBA’s is to make regular Backups at
sometimes various and very specific times of the day or night, it also
happens that at some of those times you just can’t be present to
perform a Backup, like at 3:00 AM or other uneasy time frames.
• Lucky for us, SQL Server relies on a specific service called “SQL
Server Agent” which controls SQL Jobs along with its scheduling
and intervals. The SQL Services look similar to the following image,
which in this case shows the services for an instance called “Dev”
on a SQL Server 2017 installation.

• Once we know the service is running, we proceed with the following
steps under SSMS:
1. Login to MS SQL Server with a privileged account (Admin rights)
2. Open object explorer by pressing the “F8” key (if not loaded already)
3. Expand the SQL Server Agent option
4. Right-click the “Jobs” folder and click on “New Job…”
This option opens the “New Job” form, it
contains several pages and fields. I will
explain the most relevant options for this
excerpt in the next slide.

• The “New Job” form contains five pages: (General, Steps,
Schedules, Alerts, Notifications and Targets), for our purposes and
demonstration we will only use the first three pages.
Name: This is the name of the Job and
it is unique. You may use a naming
logic by putting a prefix for the purpose
like “Backup_Full_Monthly ” or similar.
Owner: This is the user who owns the
Job. Click on the button on the right to
change it.
Category: Leave as is.
Description: This is a long text
description of the job, you need to
press CTRL+ENTER in order to create
blank lines.
Enabled: This checkbox controls the
working state of the job.

• Once you have completed filled all the required fields, saved, closed
and reopened your form, it should be similar to the following:
Please note that once we create the job
a series of new fields will show below
the “Enabled” checkbox, these fields
hold information about job source,
creation, modification, last execution
and a link to the job’s history. Also, these
fields show only after clicking the “OK”
button and reopening the form.

• Now we can go to the “Steps” page and click on “New…” to create a
new step, this is where we put our T-SQL script for the backup,
which for the purpose has to be properly parametrized as shown on
the next slide.

• On the left you can see the form, on the right you can see an
enhanced view of the script:

• The script contains a header and footer, the header portion prints
basic information about the job, server name, start date/time and the
system user, the footer prints the date/time along with a message.
• The purpose of this is to document the process on our SQL tables,
specifically on the msdb database to have a report that can be
archived or sent to others as evidence of the success or failure of
the job. But first, we need to do some additional steps:
1. Clik on the “Advanced” page of the step
2. Click on the “On success action” pull down, change it to “Quit the job reporting
success”
3. Make sure all options are marked as in the image.

• The form should look similar to this:
• Click the “OK” button to continue.

• We need to set a schedule for the Backup, click on the “Schedule”
page on the left and then on the “New…” button. A form called “New
Job Schedule” appears, there we specify the parameters for the
Backup to occur, please see the forms below, I have already
completed some of the data for you to see as an example:

• If you clicked the “OK” button on the “New Job Schedule” then you
should be seeing something like this:
• Click on the “Targets” page to continue.

• Make sure you have marked the “Target local server” option:
• Click the “OK” button, we’ll manually test this job so you can see the
results before the month!

• If you have setup everything correctly then the job should run
without any issues, but since this is not a production environment
and I won’t wait until next month, I will manually run the job by going
to the object explorer -> SQL Server Agent -> Jobs ->
Backup_Full_Monthly, right clicking it and selecting “Start Job at
Step…”
<- This is how it looks while
running.
<- This is how it looks when
it’s done

Auditing the Backup results
• We now have an automated Backup that has been audited and
documented by MS SQL Server, now we need to see the results of
that process and audit it ourselves on several steps as follows:
1. The properties of the job steps: Under SSMS, go to Object Explorer -> SQL Server
Agent (expand it), double-click on “Job Activity Monitor” -> double-click on the Job name
for the Backup -> Open the “Steps” page (on the left pane) -> Click the “Edit” button ,
select the “Advanced” page and click on
the “View” button which is located on
the middle far-right of the form.
A notepad with the report should
appear similar to the following image:
NOTE: It would be safe to copy or save the
contents of the report onto another file, this is
for a better manipulation and storage of it.

2. Querying the msdb system file:MS SQL Server logs all backup activities on the
msdb system database, most of this information can be extracted by using the select
command and the specific table(s) name(s) with the desired criteria, but this data can be
too raw to digest for auditing purposes, specially for the managers who only need a
human readable summary of such activity. I will detail each table and its contents, then I
will show the scripts on the next slide:
a. backupset: Contains a row for each backup set executed on the server.
b. backupfile: Contains one row for each data or log file of a database.
c. backupfilegroup: Contains one row for each filegroup in a database at the time of
the backup.
d. backupmediafamily: Contains one row for each media family, this includes location
and storage medium used for the backup.
e. backupmediaset: Contains one row for each media set.
• For the purpose of auditing, I will write the T-SQL scripts based on
the backupset and backupmediafamily tables only with the most
relevant fields (for screen fitting purposes the result grid will be split),
though you may use the other tables for your own auditing.

Auditing the Backup results - backupset

Auditing the Backup results - backupmediafamily

3. Querying the existence of the file: Beyond the information you can retrieve from MS
SQL Server tables you may also query the file directly with a T-SQL Script, as long as the
location is reachable or within the results we just witnessed. We will now use the Restore
statement syntax in the following order:
a. RESTORE FILELISTONLY: Displays a list of the files contained in the Backup set.
b. RESTORE HEADERONLY: Displays all the header information in the Backup set.
c. RESTORE LABELONLY: Displays information about the backup media identified
by the given backup device.
d. RESTORE VERIFYONLY: This is the restore without restore, it basically simulates a
restore testing the integrity of the backup file, however, this does not check for the
structure of the data contained within the backup file.
• On the next slide I will put these restore commands to the test based
on the location returned by the msdb tables, if the files were located
elsewhere then a relocation of the paths or UNC has to be set
properly for the commands to work.

• The T-SQL queries return values from the Backup file, the last query
returns “The backup set on file 1 is valid” which means that we are
close to 99% sure that this Backup is valid and works. To reach the
100% we need to do one final step.

• As tedious as it may seem and aside from all previous testing
performed on the Backup file, we need to achieve 100% of certainty
that it contains a restorable database in it by doing the only thing that
overrides all other possible tests, which is making a restore.
• I will show you how a T-SQL restore script looks and how it performs,
this you can consider it the final test, but before that is accomplished we
need to adjust a few things as follows:
a. Database name: Since I will restore the database on my own computer and in order to
avoid errors, the database name must be different. This would not be an issue if it were
restored on a different instance or server, but it does serve the purpose for now.
b. File location: You also need to relocate the files as they are going to fall in the same path
as the original, this is accomplished by using the “Move” option on the restore, just make
sure the paths exists on the computer.
c. File names: Optionally, you may replace the name of the restored file names.
d. STAND BY: In order to keep restoring to the database, you need to restore as a stand-by.
This puts the database in a read-only state but allows you keep restoring other backups,
either Full or Differential, also allows you to configure Log Shipping to the database.

9 minutes and 45 seconds to restore (582.026 seconds / 60) now we are 100% sure that
the Backup is good!

Personal advise to other DBA professionals
• Experience is the best teacher and the mother of all knowledge, it is
also very expensive and we always wish we had it before that
disaster or data loss happened to us. Nevertheless, it is always a
good thing to hear from other people’s experience and advise, which
is what I’m going to do by enumerating eight tips that you may want
to follow in your life as a DBA.
1. Document and organize everything you do in your job, it speaks well of you.
2. Backup all databases, test the backups by restoring them daily.
3. Know your hardware and all your resources, if available, ask for an inventory sheet.
4. Study, train, do al the research you can ahead of whatever is coming to you.
5. Define your roles depending on the type of DBA you are.
6. Set boundaries between you and the developers, don’t trust them with your DB’s.
7. Boundaries don’t mean you should become enemies, we can all coexist and learn
from one another, just never let anyone create/alter/delete objects in the production
environment without the necessary approval or supervision.
8. Love what you do, with high respect and ethics for everybody at all times, remember
that DBA’s are the main line of defense for the business recovery process.

Thank you!
If you wish to download the T-SQL code used in this presentation
you may click the link below:
https://datagrupo.com/sqlbackups/SQLBackups.txt

MS SQL Backups explained by a DBA

More Related Content

What's hot

Similar to MS SQL Backups explained by a DBA

Recently uploaded

MS SQL Backups explained by a DBA