FS
Documentation

Backup3G/EWC 5.1 Release Notes

This page was last modified 04:38, 19 February 2008.

From Documentation

Jump to: navigation, search

Contents

Overview and Features

Enterprise Windows Client

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.


New features in EWC 5.1

Simpler Configuration


Enhanced Operations



^

Installation Requirements

Software prerequisites

To install EWC 5.1 on a host, you must have:


To run EWC 5.1 at least one UNIX/Linux on the same network must have:


Disk space required

Software Approximately 10 MB in the "Program Files" directory.
Temporary Files While EWC is running: less than 10 MB in /tmp.


Related Software

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



^

Upgrading EWC 3.1 or EWC 3.1.1

Figure 1 — Installation messages—upgrading from COSbackup 3.2.6
Figure 1 — Installation messages—upgrading from COSbackup 3.2.6
  1. Download the distribution file to the target Windows host.
  2. From the Configuration menu, select COSmanager configuration > Applications .
  3. Select Application > Install .
  4. Press Choose. You will see a list of the applications that can be installed. Choose the entry titled Backup3G 5.2, and press Accept.
  5. 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.
  6. You will be asked which host is the backup3G Master host. Press this host, or choose another host.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. To copy custom files to the newly installed version press Custom. Select those files to copy and press Accept.
  12. 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.
  13. Once you have completed the copy of any custom files and the review of locally modified or patched files press Done.
  14. 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.
This completes the upgrade installation. You must now restart COSmanager for the new version of backup3G to come into affect.



^

Technical Notes: Using EWC 5.1

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

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

Figure 2 — Use of arbitrary command in backup job
Figure 2 — Use of arbitrary command in backup job


Arbitrary 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
Note
Command's run on a Windows host are run using cmd /c and are run as SYSTEM.



^

New Features in this Release

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, EWC 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 file backups that are larger than the capacity of a tape can now be accommodated.


NTCPIO file restore options

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

  1. 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.
  2. 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
  3. 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.
  4. 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.


EWC 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
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 no 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
Caution!
Altering this setting does not move or copy existing log files to the new target directory. You must copy these manually.
IgnoreWarnings no 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 no 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 no 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
Caution!
Altering this setting does not move or copy existing log files to the new target directory. You must copy these manually.



^

Known Problems in this Release

None known.



^

Hardware and OS Dependencies

Windows NT 4

Windows NT 4 is not supported by EWC 5.1. Use EWC 3.1.1 instead.


Windows 2000

None known.


Windows 2003

None known



February 2008
Copyright © 1990-2019 Functional Software. All rights reserved.