- Click the Backup Exec Button [Top left]
- Select Configurations and Settings > Alerts and Notifications > Recipient configurations.
- Click add a recipient, Click yes if a configuration pop up box appears
- Under Email Server: Type the name of the exchange server. The IP address can also be used. (i.e. exchange.com or 192.1.2.3)
- Enter in the name of the sender in the Sender Name: field. (i.e. Administrator)
- Enter in the Email address of the sender in the Sender Email address: field (Administrator@mydomain.com)
- Click OK
- In the next window that opens, enter in the user name of the person to send the notification to in the Name: field
- Check the Send notifications by Email box and then enter in the Recipient's email address (i.e. user@mydomain.com)
- Make sure to send a test Email
- Alternately, a notification can be sent via text message as well by checking the Send notifications by text message box and entering in the phone number of the device
- Click Ok and view the test Email.
Backup Exec 2012
This blog is only for information purpose and is not associated with Symantec in any way. Some solutions/configurations may differ with the actual product depending on the Service Packs/Hotfixes applied.
How to setup SMTP Email Notifications in Backup Exec 2012
Tape Device BUFFER SIZE - Tape
Tape Device BUFFER SIZE selected value is not saved in the Backup Exec 2012 User Interface
The issue is fixed with Backup Exec 2012 Service Pack 1a.
The issue is fixed with Backup Exec 2012 Service Pack 1a.
Media description - Tape
Media description is deleted after the backup job on the tape.
By Default any Media Description applied to Tape or VTL media in Backup Exec 2012 will be removed during any form of Overwrite Operation. A method to change this behaviour is available by registry modification.
Warning: Incorrect use of the Windows registry editor may prevent the operating system from functioning properly. Great care should be taken when making changes to a Windows registry. Registry modifications should only be carried-out by persons experienced in the use of the registry editor application. It is recommended that a complete backup of the registry and workstation be made prior to making any registry changes
1) Use Regedit to locate
HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec for Windows\Adamm
2) Within the ADAMM key create a REG_DWORD value called
PreserveMediaDescriptions
3) Set the value data to 1 to maintain the media descriptions during overwrite operations (default behaviour would be set the value data to 0)
How an existing Backup Exec configuration is migrated to Backup Exec 2012
When upgrading, Backup Exec automatically converts the existing
configuration to the current version. The following items provide information
about how the configuration is migrated to Backup Exec 2012. Review this
information before using Backup Exec 2012.
·
If multiple
backup-to-disk folders are on the same volume, Backup Exec 2012 converts one
backup-to-disk folder on the volume to a disk storage device. Disk
storage is a location on a locally attached internal hard drive, a USB device,
a FireWire device, or a network-attached storage device to which you can back
up data. All of the other backup-to-disk folders on the volume become
read-only so that the data can be restored from them. The read-only
backup-to-disk folders are called legacy backup-to-disk folders. Backup
Exec no longer creates new backup sets in the legacy backup-to-disk
folders. All backup jobs that were sent to the legacy backup-to-disk
folders are now sent to the disk storage device that Backup Exec 2012 creates
on the volume. Backup Exec’s data lifecycle management feature manages the
existing data in the legacy backup-to-disk folders, eventually expiring and
deleting the data according to the overwrite protection period that you
specified when you created the backup. When a legacy backup-to-disk
folder becomes empty, Backup Exec deletes it. The data lifecycle
management feature also manages the backup data on the disk storage device.
o Note: If upgrading from a release prior to
Backup Exec 2010 R2, all backup-to-disk folders that have the same drive letter
are considered as being on the same volume.
·
Removable
backup-to-disk (RB2D) folders are now called disk cartridge devices. Disk
cartridge devices are a type of storage that usually remains attached to the
Backup Exec server while you remove the media, such as RDX. If you are
not sure if the storage has removable media, you can open the Computer folder
on your Windows computer. The devices that contain removable media are listed.
You can manage data retention on disk cartridge devices by associating the
media with media sets. Media sets specify append periods, overwrite
protection periods, and vaulting periods.
·
Existing storage
device pools that contain exclusively disk storage, or disk cartridge devices,
or tape cartridge devices remain intact. Storage device pools that contain a
mix of storage device types are labeled as disk storage device pools, and all
cartridge devices are removed. New storage device pools are created to
contain the cartridge devices.
By default, Backup Exec automatically creates the following
storage device pools:
·
Any disk storage –
contains any backup-to-disk folders that Backup Exec converts to disk storage
devices.
·
Any tape cartridge
storage – contains any tape devices that Backup Exec detects as attached to the
Backup Exec server.
·
Any disk cartridge
storage – contains any disk cartridge devices that were previously used as
removable backup-to-disk folders, or that have been configured to be used as a
backup destination.
·
Any virtual disk
storage – contains the virtual disks that are on storage arrays. This pool is
created only if the Storage Provisioning Option is installed.
o Note: In a Central Admin Server Option environment,
the storage device pools that Backup Exec 2012 creates contain all of the
storage devices that are on all Backup Exec servers in the environment.
Best practices for Backup Exec 2012 Agent for Microsoft Exchange Server
Best practices include tips and recommendations to help you use
the Exchange Agent effectively. For more information about the Exchange Agent,
see the Backup Exec 2012
Administrator's Guide.
For best practices on preparing the Exchange
Server for backup, do the following on the Exchange Server:
·
Put transaction log
files on a separate physical disk from the database. If the disk that contains
the database is damaged, the transaction logs are available as a recovery
resource.
·
Set the retention
period for deleted items and mailboxes to a length of time that is appropriate
for the available disk space. The longer the retention period, the more disk
space is required. However, some retention period can prevent you from having
to restore a mailbox or database. If possible, configure the Exchange server so
that items are not deleted until a full backup is performed.
·
Make Write Cache
unavailable on the SCSI controller. Data corruption can occur if the computer
fails before the operation is written to disk.
·
Monitor the Application,
Security, and System logs for any relevant events that may affect Exchange
Server functionality.
·
Allow sufficient disk
space for maintenance and recovery procedures. Refer to your Microsoft
documentation for details.
·
Avoid making the
Exchange server a domain controller. You can more easily restore Exchange if
you don't have to restore the Active Directory first.
·
Install the Exchange
Server into a domain that has at least two domain controllers. With two domain
controllers in a domain, databases on a failed domain controller can be updated
with replication.
·
For Exchange Server
2003, ensure that the latest version of the Esebcli2.dll file is installed. If
the Esebcli2.dll file is installed in more than one location, ensure that all
locations contain the latest version.
·
For Exchange 2010, use
a Database Availability Group (DAG) with at least one passive database copy for
each database to protect against data loss. If you can make more than one passive
copy, the second passive copy should use a log replay delay of 24 hours.
·
For Exchange 2010, a
Windows 2008 SP2 or Windows 2008 R2 x64 Backup Exec server with the Exchange
2012 Management tools that are installed on the Backup Exec server is required.
·
When you run full
backups, enable the option for Granular Recovery Technology (GRT). The GRT
option lets you restore individual mail messages and folders from a database
backup without the need for a separate mailbox backup.
Note:
|
·
Change your default
staging location if you run GRT-enabled backup jobs. The default location is
used for recovery as well as staging GRT-enabled restore jobs. You should
change the location to a volume that is not your system volume for faster
performance.
·
Ensure that the
scheduled maintenance for the Information Store does not run at the same time
as the database backup. If you run these operations at the same time, it can
cause issues with the Exchange Server databases.
·
Run a regular backup
for System State and Shadow Copy Components, if applicable. These selections
back up the Internet Information Service (IIS) metabase and the Windows
registry.
·
When you run offline
backups, back up all of the files that make up the storage group, including any
.Edb and .Stm files, and all transaction log files.
·
For Exchange 2010 DAGs
that have three or more copies of the database, the consistency check can be
disabled.
The following best practices are for using the
Backup Exec continuous protection feature as part of your backup strategy:
·
To copy backup sets to
tape for off-site storage, create a job to duplicate backup data. You can
schedule the job to copy the backup data to tape before or after each
occurrence of the full backup job. The duplicate backup data job copies all of
the transaction logs and the full backup sets to tape.
·
If you duplicate
Information Store backup data to tape and then back to disk, specify the same
volume for the full and the incremental backups. The backup data must be on the
same volume if you want to restore individual items from the incremental
backup.
·
Create a custom filter
to limit the number of recovery points that appear in the Job History view.
The following best practices are for
recovering data for all versions of Exchange Information Store:
·
Be aware of the effect
of the Restore all transaction logs; do not delete existing transaction logs
option. After an operation runs with this option enabled, transactions in
existing transaction logs are applied when you start or mount the Information
Store database. If those transactions include any deletions that occurred after
the backup ran, those deletions are also applied. As a result, the very data
that you intend to recover may be deleted. In this situation, enable the Purge
existing data and restore only the databases and transaction logs from the
backup sets option. This option discards the Exchange data that was generated
after the backup. Alternatively, you can use a second recovery server. You can
also use the Recovery Storage Group feature in Exchange 2003/2007 or Exchange
2010 recovery database to perform the restore.
·
If you must use the
Microsoft Eseutil utility to repair the database, ensure that the recovery
server has sufficient disk space. You may need as much as 125% of the actual
size of the Information Store database. You can also specify another disk or
volume as a temporary location on which to run the Eseutil utility. Refer to
your Microsoft documentation for details.
·
Ensure that you
specify a valid temporary location on the Exchange server for log and patch
files. The temporary location must have enough space to accommodate the
transaction logs that you want to recover.
·
Read the Restore.env
file if issues occur when you mount a database after a restore operation.
Information in this file can help you troubleshoot issues. To read the file,
run the Eseutil utility with the /cm switch. Refer to your Microsoft
documentation for details.
·
Select the Commit
after restore completes option when you configure a restore job so that the
database can be mounted. Run the Eseutil utility with the /cc switch to perform
a manual hard recovery. Refer to your Microsoft documentation for details.
o The recovery server has the same Organization
and Administrative Group names as the source server.
o The storage groups and databases already exist
on the recovery server, and have the same names as the original storage groups
or databases.
The following best practices are for restoring
individual mailboxes and public folders for Exchange 2003:
·
If you redirect the
restore of individual mailbox or public folder items to an alternate location,
ensure that the mailbox or public folder already exists.
·
If errors about
permissions occur, try to restore to the mailbox that is associated with the
Backup Exec logon account that you used for the restore. An example of a
permissions error is Access denied.
·
After a successful
restore of public folders, you may need to rehome some or all of the folders.
Refer to your Microsoft documentation for more information.
·
If the error Unable to
attach occurs, on the Exchange server, run Fixmapi.exe. Then, retry the
operation.
·
If you cannot attach
to the mailboxes node when Outlook is installed on the Exchange server, then
stop the Exchange and Remote Agent services. Run Fixmapi.exe, and then on the
Microsoft Web site, look up any return codes. If there are no return codes,
restart the services and retry the operation.
·
If you redirect a
mailbox restore to an Active Directory in a different forest than the Exchange
server, you must associate an external account with the mailbox. Refer to your
Microsoft documentation for details.
·
If you redirect public
folder data, ensure that the Backup Exec user account has the Owner role on
both the source and destination public folders. Refer to your Microsoft
documentation for details.
·
Perform tests
periodically to ensure that disaster recovery and data recovery scenarios
produce the expected results.
·
Become familiar with
the Microsoft documentation for Exchange database management, disaster plans,
and recovery.
·
Document the Exchange
Server configuration in detail. Document any subsequent changes. Note all
hotfixes and service packs that are applied.
Best practices for Backup Exec 2012 tape and disk cartridge media management
If you use backup jobs for which Granular Recovery Technology (GRT) is enabled, there are additional best practices for media management.
For more information about tape and disk cartridge media management, see the Backup Exec 2012 Administrator's Guide.
The following best practices are for effective tape and disk cartridge media management:
- Overwrite tape and disk cartridge media periodically to keep the media family at a manageable size so that Backup Exec can rebuild the catalog if necessary. You can use a media rotation strategy so that media is periodically overwritten, or select the option Overwrite media when you run a full backup.
Subscribe to:
Posts (Atom)