Backup3G/Backup3G 5.2 Release Notes

This page was last modified 06:05, 28 August 2012.

From Documentation

< Backup3G(Difference between revisions)

Jump to: navigation, search

Current revision

1 Overview and Features
2 Installation Requirements
3 Upgrading COSbackup or backup3G to backup3G 5.2.1
4 Technical Notes: Using backup3G 5.2
5 New Features in backup3G 5.2.1
- 5.1 Multi-object backup steps
6 New Features in backup3G 5.2
7 New Features in backup3G 5.1
8 Warnings
9 Known Problems in this Release
10 Hardware and OS Dependencies

[edit]

Overview and Features

[edit]

Backup3G

Backup3G 5.2 facilitates a standard approach to backup and recovery and the management of media in multi-host, multi-vendor UNIX, Linux and Windows data centres. All the information required to run comprehensive network backups is packaged in the backup job. There is no requirement for operators or administrators to understand subtle platform dependent variations in backup commands and devices. The automation of routine backups saves time, frees up resources, and reduces the possibility of human error.

[edit]

New features in backup3G 5.2.1

Multi-object backup steps

You can now group several different files and directories together in one backup step
This enables related files and directories to be backed up together
Supports cpio format on Unix/Linux and ntcpio on Windows

Iconic file/directory choose

Easier configuration of backup steps

Improved Support for Web3G 1.2

Although earlier versions of backup3G can run under Web3G (Functional Software's Web browser interface), backup3G 5.2.1 has a number of minor changes to run more smoothly.

[edit]

New features in backup3G 5.2

Simpler Configuration

You can create backup items and add steps using a wizard as part of adding a new backup job

Enhanced Operations

A backup piece can span across 2 or more tapes
Collapse intermediate directories
Rename file if older version exists
Search also searches structured data (database) backups
You can make file searches case insensitive
Verify media will report against media database

Improved Auditing

The Backup3G audit trail logs:

killing of backup, recovery and duplicate media jobs.

[edit]

New features in backup3G 5.1

Simpler Configuration

Disable a backup job on a given date.
Re-enable a backup job on a given date.
Append a job to media based on group name.
Schedule a secondary copy of the backup media from the backup job.
Verify media after the backup job has completed.
Send notification based on success status of the backup job. The backup log can be optionally attached.
Test network communication for a given backup job, testing communications between the Master, Drive and File hosts as configured for that job.
Method sensitive forms for backup items, making it simpler to set options.
Folders can be browsed making it simpler to set up unstructured data backup items.
The incremental backup methods have been renamed to differential.
You can discover filesystems and volumes for given hosts, creating backup items for those found.
You can filter your view of backup items by host or object.
Various global settings can be set to change the behaviour of backup3G. These include:

Remote access control
Drive inactivity timeout
Direct I/O blocksize
Meta-data replication
Notification.

Enhanced Operations

The run history of a selected backup job can be viewed over various date periods.
Send notification when there are no more available media.

Improved Auditing

The Backup3G audit trail logs the start and end and level of success of:

backup jobs
media copies
re-indexing media
media library inventory
recovery jobs
meta-data replication.

The configuration audit trail logs all changes in backup3G tables.
The operations audit trail logs all action invocations from:

backup scheduling console
recovery console
media management console
drive and media library consoles
job monitor console.

Documentation

A HTML or text document can be associated with a backup job, so end users can see what Policies and Procedures the backup is supporting.
The user guide, release notes and other documentation can be viewed via your favourite browser.

[edit]

Installation Requirements

[edit]

Software prerequisites

To install and run backup3G 5.2 on a host, you must have:

COSmanager 4.2.5 or newer already installed on the host (see the COSmanager User Guide for instructions)
a backup3G distribution
a valid license key for this host (see your COSmanager distributor if you don’t have a valid license key)
sufficient disk space
COSmanager Manager access, or equivalent
the ability to open a root shell

[edit]

Disk space required

Software	Approximately 1.5 MB in the backup3G home directory.
Temporary Files	While installing backup3G: less than 1.5 MB, to hold a copy of the software distribution. While backup3G is running: less than 5 MB in /tmp.
Audit Trails	For the backup3G audit trail, about 10 - 50 MB in the system spool area. The actual amount will depend on the activity on your system (e.g. how many backups are run), and how often you archive and delete the log files.
	For the operations audit trail, about 10 - 50 MB in the system spool area. The actual amount will depend on the activity on your system.
	For the configuration audit trail, about 10 - 50 MB in the system spool area. The actual amount will depend on the configuration activity on your system.
Backup and Restore Logs	For the backup3g backup and restore logs, up to 200 MB for a small backup environments, or up to 1 GB for medium to enterprise backup environments in the system spool area.

[edit]

Running Remote Backups on Windows

The current backup3G release supports running remote backups and restores on Windows hosts which have the EWC (Enterprise Windows Client) 5.1 installed. It also supports the older EWC 3.1.1 version, though we recommend that it be upgraded. This product may be purchased separately.

[edit]

Related Software

The initial release of backup3G 5.2 coincides with the release of stacker3G 5.1 (module), VTL3G (module), DA_Oracle 5.1 (module) and duty3G 5.1 (application).

[edit]

Upgrading COSbackup or backup3G to backup3G 5.2.1

Figure 1 — Installation messages—upgrading from COSbackup 3.2.6

Download the distribution file to /tmp on the target host.
From the Configuration menu, select COSmanager configuration > Applications .
Select Application > Install .
Press Choose. You will see a list of the applications that can be installed. Choose the entry titled Backup3G 5.2.1, and press Accept.
COSmanager copies the backup3G files from the distribution file to the target directory, updates the backup3G backlog audit trail and creates the new audit trails.
You will be asked which host is the backup3G Master host. Press this host, or choose another host.
To migrate your existing COSbackup 3.2 or backup3G 5.1 release database to the newly installed version press Copy. Your existing database is copied and updated with new table columns and rows. This is not necessary when upgrading backup3G 5.2 to 5.2.1.
Media contents, media indexes and backup logs can use a large amount of disk space. You have the option to Move or Copy each of these to the new database. We recommend that you use Copy if sufficient disk space exists.
The upgrade process searches for and removes any backup items, step and backup methods that may perform a tape rewind or media scan (media verification). The removal of these is critical. If a backup job is allowed to rewind the tape by way of a backup step or the At-end command the backup may be rendered irrecoverable. Press Log to review the upgrade. Once you are satisfied, press Agree.
To migrate custom files and programs from the local directory structure, and review locally modified or patched backup3G programs start by pressing List. This allows you to review which files are consider to be custom files and which are modified versions of backup3G files.
To copy custom files to the newly installed version press Custom. Select those files to copy and press Accept.
To review the differences of locally modified files press Local. Select a file and a list of differences between the local file and the newly installed file will be displayed. There is no option to copy any locally modified files. This must be done from a root shell.
Once you have completed the copy of any custom files and the review of locally modified or patched files press Done.
To make the newly installed backup3G the default version press Accept, then press Continue. You will see a warning about non-shared databases - just press Continue to set backup3G 5.2.1 as the default.

Any automatic backup jobs are added or re-added to the cosmos crontab.

This completes the upgrade installation. You must now restart COSmanager for the new version of backup3G to come into affect.

	Caution!
	If a backup job is allowed to rewind the tape by way of a backup step or the At-end command the backup may be rendered irrecoverable.

Note

The installation and migration produces 1 or 2 log files in your /tmp directory. They are named:

Backup3G_upg.log.<reverse date and time>
Backup3G_diff.log.<reverse date and time>

Please send these to your COSmanager distributor for review.

[edit]

Technical Notes: Using backup3G 5.2

This section contains some technical notes, tips, and troubleshooting information to help you when installing or upgrading to backup3G 5.2.

[edit]

Temporary or trial licensing

Backup3G may be issued with a temporary license for use in trials or demonstrations. Temporary licenses have an in-built expiry date. You must obtain a permanent license or a new temporary license from your COSmanager distributor to keep using backup3G after the expiry date.

	Note
	Backup3G won’t install if the license key is due to expire within the next 7 days. In this case you will need to obtain a new license key from your COSmanager distributor.

[edit]

COSmanager framework version required for backup3G 5.2

Backup3G 5.2 requires COSmanager 4.2.5 or newer.

[edit]

Schedules and Schedtime

Backup3G 5.2 (as in 5.1) uses the newer, more generalised scheduling provided in COSmanager 4.2 releases. These include the datelist and schedule tables, which supersede the schedtime table (as used in COSbackup 3.2 releases). The schedtime table is now deprecated. It is important to note that the schedtime and schedule tables are maintained separately, and so changes to one table will not be reflected in the other. You should only maintain the schedule and datelist tables. You can do this via:

Backup3G configuration > Tools > Schedules , or
COSmanager configuration > Other tables > Schedule .

[edit]

Arbitrary commands can easily be run as part of a backup job

Figure 2 — Use of arbitrary command in backup job

Arbitrary Unix/Linux and Windows commands can be configured to run as a step in the backup job. Such commands are required to place an environment in a required state prior to backing up, for example, breaking a mirror. The continue/abort option can be used to cease the backup job should the command fail; if it were to continue the backup would be useless anyway.

	Note
	Command's run on a Unix/Linux host are run as root. Command's run on a Windows host are run using `cmd /c` and are run as SYSTEM.

[edit]

Media scan item removed

	Caution!
	If a backup job is allowed to rewind the tape by way of a backup step or the At-end command the backup may be rendered irrecoverable.

[edit]

Audit Trails

When backup3G is installed, three new audit trails are created: Backup3G, backup_cfg and backup_ops. By default, these are created in the system spool area (usually /usr/spool or /var/spool). The Backup3G audit trail is the primary audit trail, recording all user actions, such as:

running a backup, recovery and media duplication job, noting the exit status;
killing a backup, recovery and media duplication job;
replicating the meta-data database to a standby host;
media library inventories.

Depending on the volume of backups run, these directories may become large, so it is important that audit trail cycling be configured correctly for your site to prevent these files from growing unbounded. By default the audit trails are cycled:

Backup3G	monthly, retaining for one year
backup_cfg	monthly, retaining for six months
backup_ops	monthly, retaining for six months.

[edit]

New Features in backup3G 5.2.1

[edit]

Multi-object backup steps

There are two new types of backup methods available which enable you to backup multiple directories and/or individual files together in one step. They support either Unix/Linux using the cpio format, or Windows using the ntcpio format. Choose one of the options "Backup multiple UNIX/Linux directories and files" or "Backup multiple Windows folders and files" when you create a new backup step.

[edit]

New Features in backup3G 5.2

[edit]

A backup piece can span across 2 or more tapes

When a backup step or part of a step hits end of tape, rather that rewrite the part on the next tape, backup3G now continues on the next tape only rewriting a small amount of backed up data. By default, 8MB is rewritten on the next tape before continuing with the backup. This means that, in particular, database backups that are larger than the capacity of a tape can now be accommodated.

[edit]

CPIO file restore options

Restoring files from a CPIO backup now has the following behaviour:

When restoring a complete step, files and directories are restored as they were backed up - no renaming of older versions of files or collapsing of paths.
Collapsing of intermediate directories occurs:
- only when restoring selected files and/or directories,
- and when all selected patterns are compared, any common leading directories are removed, except if the directory already exists on disk.
For example, when restoring from a backup of /usr to /tmp/usr:
- if 1 file is selected ./share/lib/lib1.a , no intermediate directories are created
  => /tmp/usr/lib1.a
- if 2 files are selected: share/lib/lib1.a and ./share/bin/xeyes the ./share will be collapsed
  => /tmp/usr/lib/lib1.a and /tmp/usr/bin/xeyes
- if 2 files are selected: ./share/lib/lib1.a and ./share/lib/lib2.a the ./share/lib will be collapsed
  => /tmp/usr/lib1.a and /tmp/usr/lib2.a
- as above, but directory /tmp/usr/ share exists prior to the recovery, no collapsing occurs
  => /tmp/usr/share/lib/lib1.a and /tmp/usr/share/lib/lib2.a
Renaming of existing files and/or directories occurs:
- only when restoring selected files and/or directories,
- and if the file to be restored already exists, then the older one is renamed, appending [<modification date>] to the file name, just before any file suffix if there is one, otherwise to the end.
For example, restoring the file user_guide.doc, whose modification time is 1 Oct 2007 14:65 and an existing user_guide.doc exists on disk with a modification time of 4 Nov 2007 10:12, the restored file (as it is older) is restored with the name user_guide[20071001.1465].doc, and the existing file is left untouched.
Overwriting of existing files and/or directories occurs:
- only when restoring selected files and/or directories,
- and the file being restored looks like it is exactly the same as the existing file on disk (same type, same size and same modification time),
- or the file being restored and the file on disk are both >10MB in size.

[edit]

Searching for files and other objects

Figure 3 — Searching for a file belonging to a database backup

There are two ways to search for files, directories or databases to restores:

Backup3G > Search > Search indexes , or
Backup3G > Search > Search contents .

The results are displayed with the most recent matching backup at the top.

Search indexes is used to search for specific files or file patterns. File patterns can be normal file patterns (for example, pass?d*), or regular expressions. Searching can be narrowed by choosing the host, base directory (this corresponds directly to the backup item) or database, backup written before and/or after dates and case sensitivity.

Search contents is used to search for base directories, databases or database components, for example, tablespace or archive. Searching can be narrowed by choosing the host, base directory (this corresponds directly to the backup item) or database or database component or database object name, backup written before and/or after dates and case sensitivity.

[edit]

New Features in backup3G 5.1

[edit]

Generalised calendaring for automatic backups

Backup3G 5.2 uses the new schedule and datelist tables which provide more features than the old schedtime table:

You can create named datelists, which, as the name implies, contain lists of arbitrary dates which can be used to either be included or excluded from a schedule.
You can write your own program or script to determine if the current date and time is to be included in the schedule.

	Note
	As with schedtime, scheduling of automatic backup jobs is still implemented via CRON.

[edit]

Media duplication now configured as part of the backup job

Figure 4 — Defining media duplication to occur after the backup job has completed

There are two ways to automatically produce a duplicate of a backup media set after the backup job has completed. This is also known as secondary storage.

Immediate: This will immediately copy the media set used for the current backup to a new media set in the target drive after all backup steps have completed and before any post-backup commands are executed.
Next 24hrs: This will schedule the media duplication for later in the day. The primary reason for using this mode is to remove the media duplication phase from the backup window, and typically before media is collected for off-site storage.

A common scenario is to use a VTL (virtual tape library) for the primary backup storage and a removable tape (for example, SDLT or LTO) for the secondary backup storage on the premise that writing to disk will be faster than writing to tape, and that in many cases disk in less expensive than another tape library and batch of tapes.

[edit]

Verify media after the backup job has completed

Figure 5 — Verify backup media after the backup job has completed

In previous versions of backup3G (COSbackup) there was a scan item that you could include as the last step in your backup job to verify the media. In this release the item has been removed and an option to verify media after is provided with the pre/post backup commands.

The verify after option only reads the data on tape to ensure it is readable and that the size of each tape file corresponds to the sizes recorded during the backup. It does not verify the contents of the backup with what is on disk.

If the media is successfully read, but one of the tape file sizes does not correspond to what was recorded during the backup the log will report a warning.

	Caution!
	If a backup job is allowed to rewind the tape by way of a backup step or the At-end command the backup may be rendered irrecoverable.

[edit]

Sending notification of backup job status

Figure 6 — Defining notification after the backup job has completed

Notification can be configured at two levels — globally for all backup jobs, and as part of configuring a backup job. If you configure notification as part of a backup job, this overrides the backup3G global notification settings.

To define notification for a backup job:

Select the notification type
- none: do not send notification even if there are backup3G global notification settings;
- default: use the backup3G global notification settings;
- specify: override backup3G global notification settings with the following settings.
Choose from the list of authorised COSmanager users that have a notification address set, or type in one or more email addresses.
Select the severity from which to send notification. The default is warning.
For example, if you select success, notification is always sent — when the job ends successfully or with a warning or with an error, or when the job is killed.
Select the severity from which to also send the backup log with the notification. The default is warning.

The notification settings are also used to send notification if the backup job requires another media volume to continue and there are no more available media in the media library.

	Note
	To send notification via email or by other means, such as SMS, an appropriate service (for example, sendmail) must be installed and configured on the backup3G master server.

[edit]

Backup3G settings

This release introduced a number of global settings that can affect the way backup3G behaves. Settings can be changed via Backup3G configuration > Tools > Settings .

Setting

Default value

Description

AccessControl

master

master: Users are only registered as COSmanager users with their appropriate roles on the Master Backup Server. Activities that require access to remote drive and file hosts inherit the roles granted to the cosmos user. This means users no longer need to have accounts created and COSmanager roles granted for all hosts under backup3G's control.

per-host: Users require accounts and COSmanager roles granted for all hosts. This does allow for fine-grained access control, but has a mush higher administration cost.

BKP_SERVER

By setting the Backup Master host, the host information table will be automatically populated. This will authorise remote access to the current host from the Backup Master host. This setting is requested during the installation of backup3G.

BKP_DRVSERVERS

By setting the list of drive hosts, the host information table will be automatically populated. This will authorise remote access to the current host from these hosts.

DEVIO_TIMEOUT

600 (seconds)

If the tape device writer process (devio) determines that it is writing at <1KB/sec for for this number of continuous seconds, then the process and that backup step are terminated with an error 95.

DIOBlocksize

256 (KB)

Unix filesystems can be mounted for direct I/O. Direct I/O tells the kernel to not optimise disk reads and writes and just allow raw disk reads and writes. Some databases, such as Oracle, are capable of optimising their own I/O and allowing the kernel to intefere would negate the advantages. If you do have filesystems mounted for direct I/O you may find increasing the value of this setting to 1024 (KB), however this may also slightly degrade backups of filesystem mounted with normal kernel I/O control.

DIR

/var/spool/log/backup

The directory where the log files for backups, restores, media duplication and index re-creation are stored.

	Caution!
	Altering this setting does not move or copy existing log files to the new target directory. You must copy these manually.

DUTY

The value of this setting is determined every time you run backup3G. It is used to change some of the interface features available. Backup3G 5.1 operates best with duty3G 5.1.

DutiesInstalled

This setting indicates if backup3G duties have been added to duty3G. If they have not been added, changing the setting allows to add or re-install the backup3G duties to duty3G.

IDIR

/var/spool/log/inventory

The directory where the log files for media library inventories are stored.

	Caution!
	Altering this setting does not move or copy existing log files to the new target directory. You must copy these manually.

IgnoreWarnings

Backup3G produces a warning if a file is no longer available to backup or a file changes size during the backup of that file. In these circumstances the rest of the backup is still successful, so you may wish the backup to be reported as successful for service level purposes. You can do that by changing the value of this setting to yes.

If you do not want to ignore warnings for all backup jobs, you can set IgnoreWarnings on individual backup steps instead.

NotifyIncLog

warning

When Backup3G sends notification you can also include the log file produced by the job. You can control from which severity to include the log. For example, you may send notification of the backup jobs' end status all the time, but only wish the log to be sent when there is an error. Also see NotifySeverity and NotifyList.

NotifyList

A list of COSmanager users and/or email addresses to notify at the end of every backup job. This setting can be overridden at the backup job level. By using COSmanager user's notification methods other than email can be set, for example, SMS. Also see NotifySeverity and NotifyIncLog.

NotifySMS

$Time Backup job \"$Job\" $State

The template used when when sending notification via SMS.

NotifySeverity

warning

Backup3G sends notification when a backup job ends with this severity or higher. The values of severity in increasing order are success, warning, killed, error or never. Also see NotifyList and NotifyIncLog.

NotifySubject

Backup job \"$Job\" $State

The template used when when sending notification via email.

RPT_CUTOFF

17:00

As backups are usually run after normal office hours, the way you view logs should reflect this. The default value of this setting, 17:00 (5pm), was chosen as representing the start of a typical organisations backup window. This means that during normal office hours viewing today's backup logs, you will be viewing logs produced between yesterday-17:00 and today-17:00.

ReplicateMetaDB

By replicating the backup3G meta-data to another host you will have a secondary backup3G Master server. This secondary host can be any other Unix or Linux host that is acting as a backup3G drive host or backup3G client.

Only the meta-data tables that have changed are copied minimising the impact on the network.

ReplicateToHost

The host to replicate the backup3G meta-data from the backup3G Master to.

This setting is ignored if the value of the ReplicateMedaDB setting is no.

ReplicateWhen

daily

When to replicate the backup3G meta-data from the backup3G Master. Options available are daily, hourly or backup end.

This setting is ignored if the value of the ReplicateMedaDB setting is no.

ReplicateLogs

You can optionally replicate log files from the backup3G Master.

This setting is ignored if the value of the ReplicateMedaDB setting is no. Only new log files are copied minimising the impact on the network.

SDIR

/var/spool/log/backup_summary

The directory where the summary log files for backups are stored.

	Caution!
	Altering this setting does not move or copy existing log files to the new target directory. You must copy these manually.

[edit]

Notes facility

You can now attach a HTML or text file of documentation to a backup job. This file can be viewed by the user from the backup console at any time.

	Note
	There is no facility provided to create notes files—you can simply use your favourite text editor (vi, emacs etc.). Notes files should be created in the `backup_5.2/local/notes` directory.

[edit]

Warnings

Scan and rewind steps must be removed.

	Caution!
	If a backup job is allowed to rewind the tape by way of a backup step or the At-end command the backup may be rendered irrecoverable.

[edit]

Known Problems in this Release

None known.

[edit]

Hardware and OS Dependencies

[edit]

AIX

None known.

[edit]

HPUX

None known.

[edit]

Linux

None known

[edit]

Solaris

None known

Retrieved from "https://documentation.fs.com.au/index.php/Backup3G/Backup3G_5.2_Release_Notes"

+{| align="right"
+| __TOC__
+|}
 == Overview and Features ==
 <br>
+==== New features in backup3G 5.2.1 ====
+'''Multi-object backup steps'''
+*You can now group several different files and directories together in one backup step
+*This enables related files and directories to be backed up together
+*Supports cpio format on Unix/Linux and ntcpio on Windows
+'''Iconic file/directory choose'''
+*Easier configuration of backup steps
+'''Improved Support for Web3G 1.2'''
+*Although earlier versions of backup3G can run under Web3G (Functional Software's Web browser interface), backup3G 5.2.1 has a number of minor changes to run more smoothly.
+<br>
 ==== New features in backup3G 5.2 ====
 *The Backup3G audit trail logs:
-:*killing of backup, restore and duplicate media jobs.
+:*killing of backup, recovery and duplicate media jobs.
 <br>
 ==== Running Remote Backups on Windows ====
-The current backup3G release supports running remote backups and restores on Windows hosts which have the [[Backup3G/User Guide/EWC | EWC]] (Enterprise Windows Client) 3.1.1 installed. This product may be purchased separately.
+The current backup3G release supports running remote backups and restores on Windows hosts which have the [[Backup3G/User Guide/EWC | EWC]] (Enterprise Windows Client) 5.1 installed. It also supports the older EWC 3.1.1 version, though we recommend that it be upgraded. This product may be purchased separately.
 <br>
 ==== Related Software ====
-The release of backup3G 5.2 coincides with the release of stacker3G 5.1 (module), VTL3G (module), DA_Oracle 5.1 (module) and duty3G 5.1 (application).
+The initial release of backup3G 5.2 coincides with the release of stacker3G 5.1 (module), VTL3G (module), DA_Oracle 5.1 (module) and duty3G 5.1 (application).
 <br>
-== Upgrading COSbackup 3.2.1-3.2.6 or Backup3G 5.1 ==
+== Upgrading COSbackup or backup3G to backup3G 5.2.1 ==
 [[Image:Backup upg install.png|frame|Figure 1 — Installation messages—upgrading from COSbackup 3.2.6]]
 #From the Configuration menu, select {{cnav| COSmanager configuration | Applications}}.
 #Select {{cnav| Application | Install}}.
-#Press Choose. You will see a list of the applications that can be installed. Choose the entry titled Backup3G 5.2, and press Accept.
+#Press Choose. You will see a list of the applications that can be installed. Choose the entry titled Backup3G 5.2.1, and press Accept.
 #COSmanager copies the backup3G files from the distribution file to the target directory, updates the backup3G ''backlog'' audit trail and creates the new audit trails.
 #You will be asked which host is the backup3G Master host. Press this host, or choose another host.
-#To migrate your existing COSbackup 3.2 or backup3G 5.1 release database to the newly installed version press Copy. Your existing database is copied and updated with new table columns and rows.
+#To migrate your existing COSbackup 3.2 or backup3G 5.1 release database to the newly installed version press Copy. Your existing database is copied and updated with new table columns and rows. This is not necessary when upgrading backup3G 5.2 to 5.2.1.
-#Media contents, media indices and backup logs can use a large amount of disk space. You have the option to Move or Copy each of these to the new database. We recommend that you use Copy if sufficient disk space exists.
+#Media contents, media indexes and backup logs can use a large amount of disk space. You have the option to Move or Copy each of these to the new database. We recommend that you use Copy if sufficient disk space exists.
 #The upgrade process searches for and removes any backup items, step and backup methods that may perform a tape rewind or media scan (media verification). The removal of these is critical. If a backup job is allowed to rewind the tape by way of a backup step or the ''At-end'' command the backup may be rendered irrecoverable. Press Log to review the upgrade. Once you are satisfied, press Agree.
-#To migrate custom files and programs from the ''local'' directory structure, and review locally modified or patched COSbackup programs start by pressing List. This allows you to review which files are consider to be custom files and which are modified versions of COSbackup files.
+#To migrate custom files and programs from the ''local'' directory structure, and review locally modified or patched backup3G programs start by pressing List. This allows you to review which files are consider to be custom files and which are modified versions of backup3G files.
 #To copy custom files to the newly installed version press Custom. Select those files to copy and press Accept.
 #To review the differences of locally modified files press Local. Select a file and a list of differences between the local file and the newly installed file will be displayed. There is no option to copy any locally modified files. This must be done from a root shell.
 #Once you have completed the copy of any custom files and the review of locally modified or patched files press Done.
-#To make the newly installed backup3G the default version press Accept, then press Continue. You will see a warning about non-shared databases - just press Continue to set backup3G 5.2 as the default.
+#To make the newly installed backup3G the default version press Accept, then press Continue. You will see a warning about non-shared databases - just press Continue to set backup3G 5.2.1 as the default.
 :Any automatic backup jobs are added or re-added to the ''cosmos'' crontab.
 *{{cnav| Backup3G configuration | Tools | Schedules}}, or
 *{{cnav| COSmanager configuration | Other tables | Schedule}}.
+<br>
+==== Arbitrary commands can easily be run as part of a backup job ====
+[[Image:Backup item ucommand.png|frame|Figure 2 — Use of arbitrary command in backup job]]
+Arbitrary Unix/Linux and Windows commands can be configured to run as a step in the backup job.  Such commands are required to place an environment in a required state prior to backing up, for example, breaking a mirror.  The ''continue/abort'' option can be used to cease the backup job should the command fail; if it were to continue the backup would be useless anyway.
+:{{Note| Command's run on a Unix/Linux host are run as ''root''.
+Command's run on a Windows host are run using <code>cmd /c</code> and are run as ''SYSTEM''.}}
+<br>
+==== Media scan item removed ====
+:{{Caution|If a backup job is allowed to rewind the tape by way of a backup step or the ''At-end'' command the backup may be rendered irrecoverable.}}
 <br>
 When backup3G is installed, three new audit trails are created: ''Backup3G'', ''backup_cfg'' and ''backup_ops''. By default, these are created in the system spool area (usually <code>/usr/spool</code> or <code>/var/spool</code>). The ''Backup3G'' audit trail is the primary audit trail, recording all user actions, such as:
-*running a duty, noting the exit status;
+*running a backup, recovery and media duplication job, noting the exit status;
-*marking a duty as done;
+*killing a backup, recovery and media duplication job;
-*any added user comments;
+*replicating the meta-data database to a standby host;
-*re-authentication failures;
+*media library inventories.
-*attempts to run disabled duties.
 Depending on the volume of backups run, these directories may become large, so it is important that audit trail cycling be configured correctly for your site to prevent these files from growing unbounded. By default the audit trails are cycled:
 <br>
-== New Features in this Release ==
+== New Features in backup3G 5.2.1 ==
+==== Multi-object backup steps ====
+There are two new types of backup methods available which enable you to backup multiple directories and/or individual files together in one step. They support either Unix/Linux using the cpio format, or Windows using the ntcpio format. Choose one of the options "Backup multiple UNIX/Linux directories and files" or "Backup multiple Windows folders and files" when you create a new backup step.
+<br>
+== New Features in backup3G 5.2 ==
 ==== A backup piece can span across 2 or more tapes ====
-blah
+When a backup step or part of a step hits end of tape, rather that rewrite the part on the next tape, backup3G now continues on the next tape only rewriting a small amount of backed up data.  By default, 8MB is rewritten on the next tape before continuing with the backup.  This means that, in particular, database backups that are larger than the capacity of a tape can now be accommodated.
 <br>
 #*only when restoring selected files and/or directories,
 #*and when all selected patterns are compared, any common leading directories are removed, ''except'' if the directory already exists on disk.
-#:For example, when restoring from a backup of <tt>/usr</tt> to <tt>/tmp/usr</tt>:
+#:For example, when restoring from a backup of <code>/usr</code> to <code>/tmp/usr</code>:
-#:*if 1 file is selected <tt>./share/lib/lib1.a</tt> , no intermediate directories are created<br> => <tt>/tmp/usr/lib1.a</tt>
+#:*if 1 file is selected <code>./share/lib/lib1.a</code> , no intermediate directories are created<br> => <code>/tmp/usr/lib1.a</code>
-#:*if 2 files are selected: <tt>share/lib/lib1.a</tt> and <tt>./share/bin/xeyes</tt>, the <tt>./share</tt> will be collapsed<br> => <tt>/tmp/usr/lib/lib1.a</tt> and <tt>/tmp/usr/bin/xeyes</tt>
+#:*if 2 files are selected: <code>share/lib/lib1.a</code> and <code>./share/bin/xeyes</code> the <code>./share</code> will be collapsed<br> => <code>/tmp/usr/lib/lib1.a</code> and <code>/tmp/usr/bin/xeyes</code>
-#:*if 2 files are selected: <tt>./share/lib/lib1.a</tt> and <tt>./share/lib/lib2.a</tt> the <tt>./share/lib</tt> will be collapsed<br> => <tt>/tmp/usr/lib1.a</tt> and <tt>/tmp/usr/lib2.a</tt>
+#:*if 2 files are selected: <code>./share/lib/lib1.a</code> and <code>./share/lib/lib2.a</code> the <code>./share/lib</code> will be collapsed<br> => <code>/tmp/usr/lib1.a</code> and <code>/tmp/usr/lib2.a</code>
-#:*as above, but directory <tt>/tmp/usr/</tt> share exists prior to the recovery, no collapsing occurs<br> => <tt>/tmp/usr/share/lib/lib1.a</tt> and <tt>/tmp/usr/share/lib/lib2.a</tt>
+#:*as above, but directory <code>/tmp/usr/</code> share exists prior to the recovery, no collapsing occurs<br> => <code>/tmp/usr/share/lib/lib1.a</code> and <code>/tmp/usr/share/lib/lib2.a</code>
 #Renaming of existing files and/or directories occurs:
 #*only when restoring selected files and/or directories,
 #*and if the file to be restored already exists, then the ''older'' one is renamed, appending <tt>[<modification date>]</tt> to the file name, just before any file suffix if there is one, otherwise to the end.
+#:For example, restoring the file <code>user_guide.doc</code>, whose modification time is 1 Oct 2007 14:65 and an existing <code>user_guide.doc</code> exists on disk with a modification time of 4 Nov 2007 10:12, the restored file (as it is older) is restored with the name <code>user_guide[20071001.1465].doc</code>, and the existing file is left untouched.
 #Overwriting of existing files and/or directories occurs:
 #*only when restoring selected files and/or directories,
-#*and the file being restored looks like it is exactly the same as the existing file on disk (same type, size and same modification time),
+#*and the file being restored looks like it is exactly the same as the existing file on disk (same type, same size and same modification time),
 #*or the file being restored and the file on disk are both >10MB in size.
-#:For example, restoring the file <tt>user_guide.doc</tt>, whose modification time is 1/10/07-14:65 and an existing <tt>user_guide.doc</tt> exists on disk with a modification time of 4/11/07-10:12, the restored file (as it is older) is restored with the name <tt>user_guide[20071001.1465].doc</tt>, and the existing file is left untouched.
 <br>
+==== Searching for files and other objects ====
+[[Image:Backup search files.png|frame|Figure 3 — Searching for a file belonging to a database backup]]
+There are two ways to search for files, directories or databases to restores:
+*{{cnav| Backup3G | Search | Search indexes}}, or
+*{{cnav| Backup3G | Search | Search contents}}.
+The results are displayed with the most recent matching backup at the top.
+''Search indexes'' is used to search for specific files or file patterns. File patterns can be normal file patterns (for example, <tt>pass?d*</tt>), or regular expressions. Searching can be narrowed by choosing the host, base directory (this corresponds directly to the backup item) or database, backup written before and/or after dates and case sensitivity.
+''Search contents'' is used to search for base directories, databases or database components, for example, ''<tt>tablespace</tt>'' or ''<tt>archive</tt>''. Searching can be narrowed by choosing the host, base directory (this corresponds directly to the backup item) or database or database component or database object name, backup written before and/or after dates and case sensitivity.
+<br>
+== New Features in backup3G 5.1 ==
 ==== Generalised calendaring for automatic backups ====
 <br>
-==== Arbitrary commands can easily be run as part of a backup job ====
+==== Media duplication now configured as part of the backup job ====
-blah.
+[[Image:Backup 2nd storage.png|frame|Figure 4 — Defining media duplication to occur after the backup job has completed]]
+There are two ways to automatically produce a duplicate of a backup media set after the backup job has completed.  This is also known as ''secondary storage''.
+#'''Immediate:''' This will immediately copy the media set used for the current backup to a new media set in the target drive after all backup steps have completed and before any post-backup commands are executed.
+#'''Next 24hrs:''' This will schedule the media duplication for later in the day.  The primary reason for using this mode is to remove the media duplication phase from the backup window, and typically before media is collected for off-site storage.
+A common scenario is to use a [[Backup3G/VTL/User Guide | VTL]] (virtual tape library) for the primary backup storage and a removable tape (for example, SDLT or LTO) for the secondary backup storage on the premise that writing to disk will be faster than writing to tape, and that in many cases disk in less expensive than another tape library and batch of tapes.
 <br>
-==== Media scan item removed ====
-blah
+==== Verify media after the backup job has completed ====
+[[Image:Backup job verify.png|frame|Figure 5 — Verify backup media after the backup job has completed]]
+In previous versions of backup3G (COSbackup) there was a ''scan'' item that you could include as the last step in your backup job to verify the media.  In this release the item has been removed and an option to verify media after is provided with the ''pre/post backup commands''.
+The verify after option only reads the data on tape to ensure it is readable and that the size of each tape file corresponds to the sizes recorded during the backup.  It does not verify the contents of the backup with what is on disk.
+If the media is successfully read, but one of the tape file sizes does not correspond to what was recorded during the backup the log will report a warning.
+:{{Caution|If a backup job is allowed to rewind the tape by way of a backup step or the ''At-end'' command the backup may be rendered irrecoverable.}}
 <br>
-==== Media duplication now configured as part of the backup job ====
-[[Image:Backup 2nd storage.png|frame|Figure 2 — Defining media duplication to occur after the backup job has completed]]
+==== Sending notification of backup job status ====
+[[Image:Backup job notification.png|frame|Figure 6 — Defining notification after the backup job has completed]]
+Notification can be configured at two levels — globally for all backup jobs, and as part of configuring a backup job. If you configure notification as part of a backup job, this overrides the backup3G global notification settings.
+To define notification for a backup job:
+#Select the notification type
+#*'''none''': do not send notification even if there are backup3G global notification settings;
+#*'''default''': use the backup3G global notification settings;
+#*'''specify''': override backup3G global notification settings with the following settings.
+#Choose from the list of authorised COSmanager users that have a notification address set, or type in one or more email addresses.
+#Select the severity from which to send notification.  The default is ''warning''.<br>For example, if you select ''success'', notification is always sent — when the job ends successfully or with a warning or with an error, or when the job is killed.
+#Select the severity from which to also send the backup log with the notification.  The default is ''warning''.
+The notification settings are also used to send notification if the backup job requires another media volume to continue and there are no more available media in the media library.
+:{{Note| To send notification via email or by other means, such as SMS, an appropriate service (for example, sendmail) must be installed and configured on the backup3G master server.}}
 <br>
-There are now two ways to automatically produce a duplicate of a backup media set after the backup job has completed.  This is also called ''secondary storage''.
+==== Backup3G settings ====
-#'''Immediate:''' This will immediately copy the media set used for the current backup to a new media set in the target drive after all backup steps have completed and before any post-backup commands are executed.
+This release introduced a number of global settings that can affect the way backup3G behaves.  Settings can be changed via {{cnav| Backup3G configuration | Tools | Settings}}.
-#'''Next 24hrs:''' This will schedule the media duplication for later in the day.  The primary reason for using this mode is to remove the media duplication phase from the backup window, and typically before media is collected for off-site storage.
-A common scenario is to use a VTL (virtual tape library) for the primary backup storage and a real tape library for the secondary backup storage on the premise that writing to disk will be faster than writing to tape, and that in many cases disk in less expensive than another tape library and batch of tapes.
+{| border="0" cellpadding="6" cellspacing="0"
+! align="left" width="145" style="border-bottom:1px solid grey;" | Setting
+! align="left" width="240" style="border-bottom:1px solid grey;" | Default value
+! align="left" style="border-bottom:1px solid grey;" | Description
+|-
+| valign="top" style="border-bottom:1px solid grey;" | AccessControl
+| valign="top" style="border-bottom:1px solid grey;" | master
+| style="border-bottom:1px solid grey;" | '''master''': Users are only registered as COSmanager users with their appropriate roles on the Master Backup Server.  Activities that require access to remote drive and file hosts inherit the roles granted to the ''cosmos'' user.  This means users no longer need to have accounts created and COSmanager roles granted for all hosts under backup3G's control.
+'''per-host''': Users require accounts and COSmanager roles granted for all hosts.  This does allow for fine-grained access control, but has a mush higher administration cost.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | BKP_SERVER
+| style="border-bottom:1px solid grey;" |
+| style="border-bottom:1px solid grey;" | By setting the Backup Master host, the host information table will be automatically populated. This will authorise remote access to the current host from the Backup Master host.  This setting is requested during the installation of backup3G.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | BKP_DRVSERVERS
+| style="border-bottom:1px solid grey;" |
+| style="border-bottom:1px solid grey;" | By setting the list of drive hosts, the host information table will be automatically populated. This will authorise remote access to the current host from these hosts.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | DEVIO_TIMEOUT
+| valign="top" style="border-bottom:1px solid grey;" | 600 (seconds)
+| style="border-bottom:1px solid grey;" | If the tape device writer process (devio) determines that it is writing at <1KB/sec for for this number of continuous seconds, then the process and that backup step are terminated with an error 95.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | DIOBlocksize
+| valign="top" style="border-bottom:1px solid grey;" | 256 (KB)
+| style="border-bottom:1px solid grey;" | Unix filesystems can be mounted for ''direct I/O''.  Direct I/O tells the kernel to not optimise disk reads and writes and just allow raw disk reads and writes.  Some databases, such as Oracle, are capable of optimising their own I/O and allowing the kernel to intefere would negate the advantages.  If you do have filesystems mounted for ''direct I/O'' you may find increasing the value of this setting to '''1024''' (KB), however this may also slightly degrade backups of filesystem mounted with normal kernel I/O control.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | DIR
+| valign="top" style="border-bottom:1px solid grey;" | /var/spool/log/backup
+| style="border-bottom:1px solid grey;" | The directory where the log files for backups, restores, media duplication and index re-creation are stored.
+{{ caution | Altering this setting does not move or copy existing log files to the new target directory. You must copy these manually. }}
+|-
+| valign="top" style="border-bottom:1px solid grey;" | DUTY
+| style="border-bottom:1px solid grey;" |
+| style="border-bottom:1px solid grey;" | The value of this setting is determined every time you run backup3G. It is used to change some of the interface features available.  Backup3G 5.1 operates best with duty3G 5.1.
+|
+|-
+| valign="top" style="border-bottom:1px solid grey;" | DutiesInstalled
+| valign="top" style="border-bottom:1px solid grey;" | no
+| style="border-bottom:1px solid grey;" | This setting indicates if backup3G duties have been added to duty3G.  If they have not been added, changing the setting allows to add or re-install the backup3G duties to duty3G.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | IDIR
+| valign="top" style="border-bottom:1px solid grey;" | /var/spool/log/inventory
+| style="border-bottom:1px solid grey;" | The directory where the log files for media library inventories are stored.
+{{ caution | Altering this setting does not move or copy existing log files to the new target directory. You must copy these manually. }}
+|-
+| valign="top" style="border-bottom:1px solid grey;" | IgnoreWarnings
+| valign="top" style="border-bottom:1px solid grey;" | no
+| style="border-bottom:1px solid grey;" | Backup3G produces a warning if a file is no longer available to backup or a file changes size during the backup of that file.  In these circumstances the rest of the backup is still successful, so you may wish the backup to be reported as successful for service level purposes.  You can do that by changing the value of this setting to '''yes'''.
+If you do not want to ignore warnings for ''all'' backup jobs, you can set ''IgnoreWarnings'' on individual backup steps instead.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | NotifyIncLog
+| valign="top" style="border-bottom:1px solid grey;" | warning
+| style="border-bottom:1px solid grey;" | When Backup3G sends notification you can also include the log file produced by the job. You can control from which severity to include the log.  For example, you may send notification of the backup jobs' end status all the time, but only wish the log to be sent when there is an error.  Also see ''NotifySeverity'' and ''NotifyList''.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | NotifyList
+| style="border-bottom:1px solid grey;" |
+| style="border-bottom:1px solid grey;" | A list of COSmanager users and/or email addresses to notify at the end of every backup job.  This setting can be overridden at the backup job level.  By using COSmanager user's notification methods other than email can be set, for example, SMS.  Also see ''NotifySeverity'' and ''NotifyIncLog''.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | NotifySMS
+| valign="top" style="border-bottom:1px solid grey;" | $Time  Backup job \"$Job\" $State
+| style="border-bottom:1px solid grey;" | The template used when when sending notification via SMS.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | NotifySeverity
+| valign="top" style="border-bottom:1px solid grey;" | warning
+| style="border-bottom:1px solid grey;" | Backup3G sends notification when a backup job ends with this severity or higher. The values of severity in increasing order are '''success''', '''warning''', '''killed''', '''error''' or '''never'''.  Also see ''NotifyList'' and ''NotifyIncLog''.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | NotifySubject
+| valign="top" style="border-bottom:1px solid grey;" | Backup job \"$Job\" $State
+| style="border-bottom:1px solid grey;" | The template used when when sending notification via email.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | RPT_CUTOFF
+| valign="top" style="border-bottom:1px solid grey;" | 17:00
+| style="border-bottom:1px solid grey;" | As backups are usually run after normal office hours, the way you view logs should reflect this.  The default value of this setting, '''17:00''' (5pm), was chosen as representing the start of a typical organisations ''backup window''.  This means that during normal office hours viewing today's backup logs, you will be viewing logs produced between yesterday-17:00 and today-17:00.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | ReplicateMetaDB
+| valign="top" style="border-bottom:1px solid grey;" | no
+| style="border-bottom:1px solid grey;" | By replicating the backup3G meta-data to another host you will have a secondary backup3G Master server.  This secondary host can be any other Unix or Linux host that is acting as a backup3G drive host or backup3G client.
+Only the meta-data tables that have changed are copied minimising the impact on the network.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | ReplicateToHost
+| style="border-bottom:1px solid grey;" |
+| style="border-bottom:1px solid grey;" | The host to replicate the backup3G meta-data from the backup3G Master to.
+This setting is ignored if the value of the ''ReplicateMedaDB'' setting is '''no'''.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | ReplicateWhen
+| valign="top" style="border-bottom:1px solid grey;" | daily
+| style="border-bottom:1px solid grey;" | When to replicate the backup3G meta-data from the backup3G Master.  Options available are '''daily''', '''hourly''' or '''backup end'''.
+This setting is ignored if the value of the ''ReplicateMedaDB'' setting is '''no'''.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | ReplicateLogs
+| valign="top" style="border-bottom:1px solid grey;" | no
+| style="border-bottom:1px solid grey;" | You can optionally replicate log files from the backup3G Master.
+This setting is ignored if the value of the ''ReplicateMedaDB'' setting is '''no'''.
+Only new log files are copied minimising the impact on the network.
+|-
+| valign="top" style="border-bottom:1px solid grey;" | SDIR
+| valign="top" style="border-bottom:1px solid grey;" | /var/spool/log/backup_summary
+| style="border-bottom:1px solid grey;" | The directory where the summary log files for backups are stored.
+{{ caution | Altering this setting does not move or copy existing log files to the new target directory. You must copy these manually. }}
+|}
 <br>
 #'''Scan and rewind steps must be removed'''.
+#:{{Caution|If a backup job is allowed to rewind the tape by way of a backup step or the ''At-end'' command the backup may be rendered irrecoverable.}}
 <br>
 <br>
 ----
-<div style="float:right;">December 2007</div>Copyright © 1990-{{CURRENTYEAR}} Functional Software. All rights reserved.
+Copyright © 1990-{{CURRENTYEAR}} Functional Software. All rights reserved.

Search

Backup3G/Backup3G 5.2 Release Notes

From Documentation

Current revision

Contents

Overview and Features

Backup3G

New features in backup3G 5.2.1

New features in backup3G 5.2

New features in backup3G 5.1

Installation Requirements

Software prerequisites

Disk space required

Running Remote Backups on Windows

Related Software

Upgrading COSbackup or backup3G to backup3G 5.2.1

Technical Notes: Using backup3G 5.2

Temporary or trial licensing

COSmanager framework version required for backup3G 5.2

Schedules and Schedtime

Arbitrary commands can easily be run as part of a backup job

Media scan item removed

Audit Trails

New Features in backup3G 5.2.1

Multi-object backup steps

New Features in backup3G 5.2

A backup piece can span across 2 or more tapes

CPIO file restore options

Searching for files and other objects

New Features in backup3G 5.1

Generalised calendaring for automatic backups

Media duplication now configured as part of the backup job

Verify media after the backup job has completed

Sending notification of backup job status

Backup3G settings

Notes facility

Warnings

Known Problems in this Release

Hardware and OS Dependencies

AIX

HPUX

Linux

Solaris