• Because the data is encrypted at the backup device, the data crosses the network unencrypted.

Software encryption is available on all backup devices. When you run a backup with software encryption, the encryption takes place at the Remote Agent. This means that the data is encrypted as it passes over the network to the Backup Exec Media Server. When using software encryption, you should enable software compression for your backup jobs. This is because encrypted data doesn’t compress well, and if you use hardware compression, the compression takes place on the backup device, after the data has been encrypted. Software compression takes place on the Remote Agent, before encryption takes place, so the data should be more compressible. The disadvantages of software encryption are:

• Because it takes place on the Remote Agent, there may be a performance impact on your backup speed.

Needless to say, if you use encryption, you should ensure that your encryption passphrase is well protected, as if you lose your Media Server, you’ll need the passphrase to perform a restore.

1. Don’t buy Backup Exec (yet). If you’re installing Backup Exec for the first time, make use of the 60 day trial. Evaluate which agents and options you need to buy for the first 30 days or so, then buy what you need and enter the license keys before the 60 days is up. By buying once, and buying the right options, you minimise wasted expenditure, and simplify relicensing in the future, when it all needs renewing at the same time.
2. Start simple. Before you install all the agents and options in the trial, and select every tickbox, just install the core components to start. Make sure you understand them before you add the agents and options, and then add them one-by-one. Backup Exec’s design allows you to do this simply. By doing this you know which bits of your backup policy are dependent on each option.
3. Use the Administrator’s Guide. This contains all the technical detail of how to install and operate Backup Exec. Have the PDF downloaded and to hand. Yes, it’s a large document, but that’s because it contains a lot of information. It’s logically laid out, and usually it will contain the answer to your question.
4. Don’t assume that it doesn’t do what you want. Backup Exec has a lot of functionality, and it scales greatly from single-server environments to environments with thousands of servers. If you need it to do something backup related, usually it will do it, though it may not be in the way you initially envision.
5. Understand OPP (Overwrite Protection Period) and APP (Append period). Understanding these two small terms can greatly help you decide and configure your media rotation strategy. Failing to understand them can lead to a lot of “Why is it doing that”-type questions.
6. Let Backup Exec manage your media. Backup Exec includes rules that define how your media is selected, and it can run reports to tell you what media to move off-site. Combine these with a sensible strategy, and all you need to do is what the report tells you to do.
7. Don’t skimp on hardware. If you’re backing up to tape, buy a device that has a high throughput. If you’re backing up to disk, make sure your disks can read and write at a high speed. You’ll be shuffling data through network cards and controller cards, so make sure the server running Backup Exec has plenty of bus bandwidth. Often when people query the performance of Backup Exec, it’s the underlying hardware that’s the bottleneck.
8. Test. We backup to restore, not for the sake of it. If you’re backing up a system for disaster recovery purposes, then finding out that you have an issue when it’s too late can be very costly.
9. Have a support contract. At risk of sounding like a sales pitch, a support contract will enable you to do two things. Firstly, if you have a problem, you can contact support! Symantec Connect is a great resource, but sometimes for extremely technical problems, Symantec Support are the people you should be speaking to. Secondly, it allows you to upgrade to the latest version of Backup Exec. The latest version includes not only the latest features, but also the latest support for applications, so when you go to upgrade your Exchange server or your SQL server, Backup Exec will probably already work with it. This saves you then having to re-purchase Backup Exec for the latest version. Buying a support contract each year works out cheaper than re-purchasing Backup Exec every couple of years.
10. Have a backup strategy. Don’t forget that Backup Exec is just a tool. We don’t backup for the sake of it. You should have a strategy that defines what you want to backup, when, how, to where, how long you will retain it and so on. Backup Exec will help you implement this, but the strategy itself, and the understanding of what you are protecting, how and why is more important than the software itself.

So to move to the barcode labels, apply the barcodes to your existing tapes, then insert them into your tape library. Once loaded, and the library has done its own inventory, you can scan the library in Backup Exec, and the tapes will show up, with the new label, but showing as unknown media. Your old labels will also show in All Media, as Backup Exec doesn’t know that they are the same tapes.

You can then inventory the loader in Backup Exec, and as each tape is read, the media ID will be recognised as that of the old media. The old label for the tape will disappear from All Media, and the new label will show the correct media set, append and overwrite protection times for the tape.

Backup Exec for Windows Servers Ports:

Backup Exec for Windows Servers Listening Ports:

First, it is important to understand the difference between using a port for listening versus for dynamic or ad-hoc communication. When Backup Exec for Windows Servers is not running any operations, the various services are listening on ports for incoming communication from other services and/or agents. During operations such as backups, a Backup Exec for Windows Server (9.x & 10.x) will first communicate to the Remote Agent on the static listening port (control connection) and then pass data back and forth using dynamic (ad-hoc) ports that are either random (by default) or can be configured to use a specific range. More detail on limiting the port ranges for Remote Agent communications can be found in the Related Documents area at the bottom of this document.

<!–[if !supportLineBreakNewLine]–>
<!–[endif]–>

Backup Exec Continuous Protection Server Ports:

Backup Exec Continuous Protection Server “Local Only” Ports:

<!–[if !supportLineBreakNewLine]–>
<!–[endif]–>

Backup Exec Desktop and Laptop Option Ports:

Backup Exec System Recovery Client Ports:

Backup Exec System Recovery Manager Ports:

Backup Exec System Recovery Retrieve Ports:

1. GRT backup requests backup data from Exchange server
2. BE Media Server Creates IMG folders in B2d location
3. Data is sent from Exchange server to BE Media Server (unless local)
4. Media Server also requests current ESE.dll version from Exchange Server and writes this to the IMG folder
5. Finally, a test is run against the database using the VFF (virtual file filter EDBProv.dll)
6. The VFF uses ESE.dll to read the Exchange database to make sure it is consistent and that we can recover data from it
7. Backup reports successful (or failed if error conditions are encountered)

Restore from Backup to Disk of Exchange granular mailbox, or public folder, data with GRT enabled:

1. Restore selection data is generated dynamically from IMG backup of Exchange database
2. BE uses the VFF with ESE to generate restore selections
3. VFF puts hard links to .edb and .stm files in vdb_date_xxxx folder
4. Restore job extracts data from IMG folders using VFF/ESE and feeds this to RAWS on Exchange Server
5. RAWS on Exchange Server uses MAPI to write data back to the Exchange database much as if it were from a legacy type backup

Backup to Tape of an Exchange Information Store database with GRT enabled goes through the following steps:

1. GRT backup requests backup data from Exchange server
2. Data is sent from Exchange server to BE Media Server (unless local)
3. BE job engine writes Exchange data to tape in same IMG folder format used to disk
4. Media Server also requests current ESE.dll version from Exchange Server and writes this to the IMG folder on tape
5. MAPI is initialized on the Exchange server by RAWS to gather granular restore data
6. Granular restore data gathered from MAPI session on the Exchange server is written to catalog
7. Granular Catalog data is retained on disk and written to tape
8. Backup reports successful (or failed if error conditions are encountered)

Restore from Backup to Tape of Exchange granular mailbox, or public folder, data with GRT enabled:

1. Restore selection data is provided by catalog data gathered at the end of the backup by MAPI on Exchange server
2. User selects granular mailbox data ONLY (NO Public Folder Granular data is available) to restore
3. Entire set data (all IMG folder data) for that Exchange IS backup job is written to staging area on disk location specified by user
4. Restore job extracts data from IMG folders using VFF/ESE and feeds this to RAWS on Exchange Server
5. RAWS on Exchange Server uses MAPI to write data back to the Exchange database much as if it were from a legacy type backup

Again, the things to note here are the differences between the backup to disk method versus the backup to tape method for backups and restores.

1. On backup, the backup to disk folders do not need to write catalog selections for the Exchange data following the backup. The restore selections are generated dynamically from the IMG folders which contain the complete Exchange IS database in its native format. This is read by BE using the VFF (EDBProv.dll) and the ESE.dll provided from the Exchange server.

2. With the backup to tape, on the other hand, the granular restore selections must be gathered and written to a regular catalog to be browsed by the user when creating restore selections. This is accomplished by RAWS using MAPI on the Exchange server to gather the data from the Exchange server using Active Directory.

3. The restore process itself (aside from the initial restore selection creation) is essentially the same, other than, if the data is coming from tape, it has to be dumped to the staging area on disk first prior to the extraction of items and the restoration process.

4. Public Folder granular restore data will NOT show up in restore selections if the backup job is written to tape. This is a limitation of MAPI. We are not able to get enough information from Active Directory to associate the Public Folder data with its actual location. This is not a problem with restore selections from backup to disk folders due to the dynamic way we can read the Exchange database using the VFF technology.

You can look at the tape’s properties in the media view in BE too, which tells you the number of hard (unrecoverable) and soft (recoverable) errors for each tape. Tapes with hard errors are bad, and should probably be retired.

So how are online and offline media defined?

Backup Exec uses these locations to determine which media to use for backups. While vaults do not affect the media selection process, they can be used to mark which media are off site, which can then be used for reports to coordinate the movement of media off site, and also to reconcile the contents of offline vaults.

Online media is media which is immediately available to Backup Exec.
Offline media is media which is not immediately available to Backup Exec.
The other alternative is media stored in a vault.

For example:
A tape which is in the drive is online.
A tape which is not in the drive if offline.
Alternatively an alternative location (such as an off-site store) may be defined as a vault.

A backup-to-disk file which is still on the disk is online.
A backup-to-disk file which is not on the disk is offline.
Backup to disk files cannot be moved to a vault.

For the purposes of simplicity, we’ll assume you are backing up files based on the archive bit. This is a marker on each file, which gets “turned on” when a file is created or modified. In Windows you can see it by viewing a file’s advanced properties (It’s called File is ready for archiving).

When you perform a full backup, every file included in your selection lists (apart from those excluded by active file exclusion) is backed up, and the archive bit is “turned off” on each file.

When you perform an incremental backup, every file included in your selection lists (apart from those excluded by active file exclusion) that has the archive bit “turned on” is backed up, and the archive bit is “turned off” on each file.

When you perform a differential backup, every file included in your selection lists (apart from those excluded by active file exclusion) that has the archive bit “turned on” is backed up, but the archive bit is not changed at all.

This means that instead of performing full backups each night, you can avoid backing up the data that has not changed. This saves time and storage space.

Let’s look at two typical examples:
Company A, Company B and Company C each have 100GB of data to backup, and each day 1 GB of that data changes.
Company A performs a full backup each night.
Company B performs a full backup on each Monday night, and an incremental backup each other night.
Company C performs a full backup on each Monday night, and a differential backup each other night.

Company A will backup 100GB of data each night.
Company B will backup 100GB of data each Monday night, and 1GB of data (the changed files) each other night.
Company C will backup 100GB of data each Monday night, and 1GB of data on the Tuesday night. On the Wednesday night, between 1 and 2 GB of data will be backed up, depending upon whether the files changed on Wednesday were the same files changed on Tuesday. By Friday, between 1 and 4 GB of data will be backed.

So Companies B and C will spend far less time (and resources) backing up than Company A. Whether Company B spends much less time backing up than Company C depends upon their data usage.

So how does this affect the restore process?

Let’s assume Companies A, B and C all have a catastrophic failure on a  Monday morning.

Company A can restore from the Friday night media. Nothing else is needed. If Friday’s tape won’t restore for some reason, they can try Thursday’s tape.
Company B will need to restore from the previous Monday night backup. Then the Tuesday, Wednesday, Thursday and Friday backups will each need to be restored (in order).
Company C will need to restore from the previous Monday night backup, then restore the Friday night backup.

Obviously Company A’s recovery will be quickest, followed by Company C, then Company B.

There remains a potential problem, however for Companies B and C. If a file has been deleted, this information does not get stored on the backup tape (unless you use the Advanced Disk-based Backup Option, but we’ll ignore that).
If a file existed on the Monday night for Company C, but was deleted during the week, it will be restored from the Monday night backup, and when the Friday backup has been restored, the restored file will still exist, even though it wasn’t there when the Friday night backup was taken.
Similarly, for Company B, If a file existed on any weeknight for Company B, but was deleted during the week, it will be restored from the Monday night backup, or the backup of the day it was created, and when the Friday backup has been restored, the restored file will still exist, even though it wasn’t there when the Friday night backup was taken.

As a result, Company C may have some files around which they don’t expect to be there. Company B may have many more! If you have an application which relies on the presence or absence of files, this may cause issues.

Versions of Backup Exec which can be upgraded directly to version 12.5 are:

• Backup Exec 11
• Backup Exec 12

During installation of version 12.5, Backup Exec will detect the previous installation and offer to upgrade it.

Previous versions cannot be upgraded directly to version 12.5, however there is a way around this. By installing version 11d then this may be used as a stepping-stone to upgrade to 12.5.

By upgrading an existing installation, jobs, catalogs and other data will be retained.

When Backup Exec is running normally, it uses the Microsoft SQL Server 2005 instance to store its configuration. Because you don’t want to use the SQL Agent to backup Backup Exec’s SQL instance, the Backup Exec Database is routinely dumped to a file (BEDB.bak), which will be included in the filesystem backup. The SQL .mdf and .ldf files won’t be included, as they’re automatically excluded, and they’d be locked in use anyway. There should also be some $4idr files from the initial installation in there too.

When you do a disaster recovery on a Backup Exec server, there’s no working SQL instance, as the .mdf and .ldf files are missing. The BE Server service notices this (somehow), and will attempt to recover the SQL instance, by restoring from the $4IDR files and the BEDB.bak file.

The error message is reported when Backup Exec cannot recover the SQL instance from the BEDB.bak and $4idr files.

The database recovery log can be found in the Backup Exec Logs folder, called dbrecover.log. This provides detailed information on the recovery process.

Installations that have been upgraded from older versions of Backup Exec may look in the wrong folder by default for the recovery files.