VBAK

Best Practices

V5.60

Table of Contents

Important Note

File System Backup task

Microsoft SQL Backup Task

Microsoft Exchange DR Backup Task

Microsoft Exchange Mailbox Backup Task

Retentions

Schedules

Encryption

Upgrading The Vbak Agents

Open Transaction Manager vs. Open File manager

Important Note

Please check the download website on a regular basis to ensure you are using the latest software.

You will also be informed of any new software releases by means of a message header on the daily e-mail report, an example is shown below, these will be listed for a period of 30 days.

Latest Agent Release (5.60) is now available for download from

File System Backup task

When creating a file system backup, it is advisable to ensure that files and folders that are not required (i.e. not business critical), are excluded.

  1. Exclude extensions that are not required, for example:-

c:\*.tmp–temporary files

c:\*.lnk–link files

c:\*.cab–windows install files

c:\*.mp3-music files

c:\*.aac–nokia music files

c:\*.avi–movie files

It is worth visiting a web site that lists the latest extensions and ascertaining which extensions relate to which application.

Obviously if some of these are required by the business, then they need backing up.

  1. Exclude folders that are not required, for example:-

c:\temp–temp folder

c:\recycler–the recycle bin

c:\System Volume Information–system restore folder

c:\winnt\system32\Config

  1. Exclude files that are not required, for example:-

c:\pagefile.sys

  1. Exclude any data/directories that are being backed up via a Plug-in, such as Exchange or SQL, for example:-

c:\Program Files\Exchange\Data-MS Exchange default location

c:\Program Files\MSSQL\Data-MS SQL default location

  1. Certain system databases cannot be backed up whilst in use i.e. WINS and DHCP., for example:-

C:\WINNT\System32\WINS\*.*

C:\WINNT\System32\DHCP\*.*

Exclude these folders from the file system backup and create a separate task (that also includes the System Sate/Service DB’s) for just these folders. You would need to include a custom command in the schedule to run a batch file that stops/starts these services as required to ensure a consistent backup.

Another alternative is to install the OTM/OFM option (licensed option) and backup as part of the file system backup

  1. It is recommended to create a separate backup task for the system/services database and schedule this at a less frequent interval.
  1. If Open File Manager (Windows) or Open Transaction Manager (Novell) are being used, stagger the backup tasks so they do not overlap each other. If one OFM/OTM task starts while another is running, both will fail due to the way in which OFM/OTM manage the cache.

Microsoft SQL Backup Task

Flat File Backup or On-line backup via Plug-in

It is possible to use SQL’s own maintenance task to backup a database to a file and back this up using a normal file backup task.This has the advantage of the file being local on the server available for immediate restore.However, the disadvantage is that addition disk space is consumed on the server for this “copy” and that it is still required to be backed up off-site.

We would recommend the use of a VBAK SQL Plug-in for the following reasons:-

  1. It is an on-line backup, in that the SQL service does not need to be stopped.
  2. The backup is transmitted immediately over the wire on off-site.
  3. No local disk space is consumed by a database db.

Default SQL Databases

SQL has the following four default databases that are required for normal operation:-

Master

Model

MSDB

Tempdb

These maintain configuration information about SQL and should be backed up at least once a moth or whenever they are known to have changed. For this reason create a specific task to include – Master, Model & MSDB but exclude Tempdb.

Customer Databases

These should be backed up to suit the customer’s requirements i.e. daily, weekly, monthly, etc.

You can either create a separate task for each DB or include a number in the same task.

NOTE:

Please remember that whenever a new database is created in SQL that it is not automatically included and that you have to add it to a task or create a new one.

Full or incremental

The difference between Full and Incremental is that Full will backup the entire database, while Incremental will only backup the transaction log files. During a restoration, the log files will be played back to achieve the most up to date restore since the last (Full) backup. It is therefore recommended that if times permits, a Full backup is preformed.

Microsoft Exchange DR Backup Task

Permissions

The account being used to perform the backups must be a member of the following:-

Administrators

Domain Admins

Domain Users

Enterprise Admins

Group Policy Creator Owners

MS Exchange-DR

There are a number of ways to backup MS Exchange. It can be backed up locally using NTBackup to create a flat file e.g. c:\exchange.bkf, this then can be backed up by VBAK or you can use the Exchange Agent/Plug-in backup option.

With either option, it is worth excluding the area where MS Exchange is stored from any other backups i.e. c:\exchange.

MS Exchange Agent/Plug-in

The advantages of doing an MS Exchange Agent/Plug-in backup are

  1. Only one backup is done.
  2. The backup is usually performed out of hours and therefore doesn’t impact on internet bandwidth when staff are present.
  3. There will a need to perform only one restore to recover the Exchange databases.

The disadvantages of doing an MS Exchange Agent/Plug-in backup are

  1. Restores will have to done across the internet and could take longer.

Are there any performance or sizing limitations with the Exchange DR plug-in?

While there is no limit to the size or number of Exchange databases which can be captured by the plug-in, to improve backup and restore performance of larger Exchange servers, VBAK now supports parallel backups of Exchange storage groups with V5.30 of the VBAK Exchange DR plug-in. This allows separate storage groups to be backed up or restored simultaneously, should line bandwidth allow.

With larger Exchange databases (>100GB), database administrators should consider organising the Exchange server into two or more storage groups and multiple databases. This configuration not only helps to speed up backups, but may also improve overall performance of the Exchange server.

The option to truncate the transaction logs is only effective when backing up the Storage Groups on an exchange server, if you are backing up the individual databases, this option has no effect.

Full or incremental backup?

The backup type Full, using a Delta (changed data) technique, backs up and optimizes all the changes in a MS Exchange (.edb, .log, etc) that have occurred since the last backup. This data is added to the original safeset to complete the entire backup safeset. Using Full with the delta technique saves a great deal of time, as only changes are transmitted to the Vault.

Incremental backups are transaction logs only. To produce a complete picture of the up-to-date MS Exchange database the incremental transaction logs are added to the safeset. Incremental backups take the least amount of time to perform. But during a restoration, the logs files will be played back to achieve the most up-to-date restore since the last backup. On MS Exchange 5.5 circular logging must be disabled for incremental backups to work.

Depending on bandwidth, it is recommended that full backups are performed periodically. Ideally, if bandwidth permits, perform a Full every time.

When backing up MS Exchange it is recommended not to use Open Transaction Manager or Open File Manager. The backup does not benefit from OTM or OFM, in this case. Also, using OTM or OFM slows down the backup. If using Open File Manager then exclude the MS Exchange folder.

Microsoft Exchange Mailbox Backup Task

MS Exchange-MAPI

Permissions

1. The account being used to perform the backups must be a member of the following:-

Local Administrators

Domain Admins

Domain Users

If connection to the Exchange server through MAPI still fails, the user may need to also be a member of one or all of the following groups:-

Enterprise Admins

Group Policy Creator Owners

Schema Admins

2. The user must have the following assigned to it in Local Policies/User Rights

Act As Part Of The Operating System

Log On As A Service

The account must have a mailbox and have received at least one email; it is recommended that you use Microsoft’s Profman2 to create this mailbox; it must then be delegated Full Administrator access at the organisation level from the Exchange System Manager.

If PST restore functionality is required, on a machine that has Outlook installed, search under C:\Program Files\Common Files\ for a file called mapisvc.inf. When the file has been located, copy it to C:\Windows\System32 on the Exchange server. If the file already exists, on the Exchange server, rename it and copy the new version from the Outlook machine.

An important note regarding the Mailbox backup is that it takes 4 to 8 times longer per gigabyte to perform than a DR backup. This is primarily because Microsoft optimized the backup protocol for backing up the entire DB, not for performing backups at the mailbox or folder level. Also, for mailbox and folder level backups, a pre-scan is required which can slow the process. The pre-scan looks through the mailboxes for messages that have been sent to more than one recipient, so that only one copy of thatmail message will be backed up.

On smaller Exchange servers with less than 100 mailboxes, all mailboxes may be backed up with a single MAPI task. However for larger Exchange servers, it is recommended that MAPI backups are broken down between important users (Such as upper management), users who require frequent restoring of messages, and ‘regular’ users.

To ensure that backup and recovery times for mailbox backups remain reasonable, it is recommended that backups are limited to no more than 100 mailboxes or around 50GB of data. In the event that more than one mailbox backup task is created, these can be scheduled to either run after each other, or run at the same time. It should be noted that mailbox backups are very system intensive, so running more than one Mailbox backup simultaneously should only be attempted on Exchange servers with multiple processors and no less than 1GB of physical memory. In addition, since Mailbox backups can impact system performance, it is suggested that Mailbox backup tasks are done when there few or no users accessing the Exchange server.

Due to this increase in the length of the backup and because the DR and MAPI cannot run together, careful scheduling of these tasks must be performed.

Retentions

On the Agent Configuration window click on the Retentions tab to view, edit or create retention settings. Retention Name is the name given to the retention policy, Days Online is the number of days the minimum number of days the backups will be kept online and Copies Online specifies how many copies of the data will be held online at any one time.

To mirror a tape based Monthly, Weekly, Daily backup rotation, the following retention policies below, can be used as a guideline:

NameRetention (In Days)Online Copies

Daily71

Weekly311

Monthly3651

The above retention policy can be scheduled with a daily backup using the daily retention runs Monday to Thursday, with a weekly backup using the weekly retention, running every Friday. On the last Friday (Or last day of the month), a Monthly backup could run, using the Monthly retention.

While in the above example, it looks like only 1 copy will be held online for each retention, data will not be ‘expired’ until both the retention AND the copies criteria are both met. So for the daily retention, a backup done on the Monday will not be removed until it is 7 days old, a backup done on the Tuesday will also be kept for 7 days. So for the above retention settings on backups done Monday to Friday, the Monday to Thursday backups would be replaced each week, with each Friday’s backup being kept for a month, with the month end backups would be kept online for a year.

Customised retention settings can be created for individual tasks, as well as different schedules assigned to different VBAK agents, and can be configured for specific data retention needs

Schedules

Select Backup, Synchronise or Custom Commandfrom the Schedule wizard command window and click Next >.

If either Backup or Synchronise ore selected, the Task List window is displayed Select a task and click Next >. If Backup was selected, then the retention window will appear to select the retention scheme, the next window allows you to set how long the backup will run once it has started, this can be in either hours or minutes. Checking the Disable deferring box will allow the backup to run until completion, regardless of how long it will take. The quick file scanning option only scans for new files and files that have changed since the last backup, un-checking this option will slow file scanning down, as each file that has changed will be read to find out how much data has changed. Once the backup window has been set, click Next >.

If Custom Command was selected, clicking next takes you to the Custom Command window, where scripts can be scheduled to run before backups. The custom command should be entered here. Once completed, click Next >.

There are 3 options for setting up schedules, Weekly, where you can specify which days of the week a backup will run, Monthly, where specific days of the month can be chosen and Custom, which is used when the backup cycle and days when the backup should run can vary.

Daily

The daily backup allows you to select the days of the week that the schedule will run, by checking or un-checking specific days of the week. The start time specifies when the schedule will start.

Monthly

The monthly backup uses a command window, where days of the month are listed. These are the days in the month that a backup should run, and can be a single date, a list of dates, or ‘LAST’ to specify that the backup should run on the last day of the month.

For example, entering 28 will make the backup run on the 28th of the month, 1,7,21,28 will make the backup run on the 1st, 7th, 21st and 28th of the month.

Custom

To run a backup on, for example, the last Friday of the month, the custom schedule option must be used. This uses a command format similar to the CRON command format used in Unix. The command is broken up with a ‘/’, and the format is start minute/start hour/day/month/day of week.

The permitted values are:

Start Minute0 to 59

Start Hour0 to 23

Day1 to 31

Month1 to 12

Day of week0 to 6(Where 0=Sunday)

Values such as day, month and day of week can be replaced with ‘*’, which means every time. ‘LAST’, as with the monthly backup, means the last day of the month.

For example, to create a custom schedule starting the backup at 23:00 on the last Friday of the month, the format would be:

00/23/25-31/*/5

This will start a backup on any Friday falling between the dates of the 25th and 31st on any month at 23:00.

Examples

First Saturday of the month0/23/1-7/*/60/23/-23:00 – time backup task runs

/1-7/-first Saturday could fall on any day between 1 to 7

/*/-month is set to all by using *

/6-Saturday is represented by day number 6

Last Saturday of the month0/18/25-31/*/60/18/-18:00 – time backup task runs

/25-31/-last Saturday could fall on any day between 25 to 31

/*/-month is set to all by using *

/6-Saturday is represented by day number 6

Prioritising Schedules

Schedules are prioritised by the order in which they appear in the schedule list. To give week end and month end schedules priority over the daily schedules, they must appear above the daily schedules in the list.

To give a schedule a higher priority, select the schedule you want to prioritise, and click on the Move Up button on the right of the window. This will move the selected schedule one place up in the list. Continue clicking on the Move Up button until you have the schedule in the position you want in the list. If you find you have prioritised the selected schedule too high in the list, use the Move Down button to move the schedule further down the list.

If you are running both DR (Database) and MAPI (Mailbox) tasks on an exchange server, it is advised that you prioritise the DR task schedules above the MAPI task schedules to ensure that DR backups take priority. In the case of a disaster, the DR backups will be required to get the Exchange server(s) back up and running as soon as possible.