710-97 - Archive Server 9.7.1 Administration

Archive Server 9.7.
1
Administration
Learning Services course 710-97
August 2009
Impressum Learning Services course material
Revision 9.7.1d
Author: Learning Services
Date: August 2009
Copyright © 2009 Open Text Software GmbH

All rights reserved, including those regarding reproduction, copying or other use or
communication of the contents of this document or parts thereof. No part of this
publication may be reproduced, transmitted to third parties, processed using electronic
retrieval systems, copied, distributed or used for public demonstration in any form without
the written consent of IXOS SOFTWARE AG. We reserve the right to update or modify
the contents. Any and all information that appears within illustrations of screenshots is
provided coincidentally to better demonstrate the functioning of the software. IXOS AG
hereby declares that this information reflects no statistics of nor has any validity for any
existing company.
© 2009 by Open Text Corporation. The copyright to these materials and any
accompanying software is owned, without reservation, by Open Text. These materials
and any accompanying software may not be copied in whole or part without the express,
written permission of Open Text. The information in this document is subject to change
without notice. All rights reserved. Printed in Canada.
Open Text Corporation is the owner of the trademarks Open Text, ‘Great Minds Working
Together’, and Livelink, among others. This list is not exhaustive. All other products or
company names are used for identification purposes only, and are trademarks of their
respective owners.
Trademarks SAP, R/3, SAPmail, SAPoffice, SAPscript, SAP Business Workflow, SAP ArchiveLink:
SAP AG
UNIX: Unis Systems Laboratories, Inc.
OSF, Motif, OSF/Motif: Open Software Foundation, Inc.
X Window System: Massachusetts Institute of Technology
PostScript: Adobe Systems, Inc.
FrameMaker: Frame Technology Corporation
ORACLE: ORACLE Corporation, Kalifornien USA
Microsoft, WINDOWS, EXCEL, NT: Microsoft Corporation
Intel, Intel Inside: Intel Corporation
Other product names have been used only to identify those products and may be
trademarks of their respective owners.
Table of Contents
1 Course Objectives and Contents
710 - Course objectives ................................................................................................................. 1-02
710 - Contents overview ................................................................................................................ 1-03
Where to go from here................................................................................................................... 1-04
2 Archiving with Open Text

Chapter overview ........................................................................................................................... 2-02
Fundamental Aspects of Archiving ................................................................................................ 2-03
Archive Server ............................................................................................................................... 2-04
Storage technologies used by Archive Server............................................................................... 2-05
Supported Storage Platforms ........................................................................................................ 2-06
Opticals – DVD, WORM, UDO ...................................................................................................... 2-07
Comparison of Optical Media Types ............................................................................................. 2-08
CAS – Content Addressed Storage – Example: EMC Centera..................................................... 2-09
SAN – Storage Area Network – Example: Hitachi Data Retention Manager ................................ 2-10
NAS – Network Adressed Storage – Example: NetApp NearStore (SnapLock) ........................... 2-11
NAS – HSM – Hierarchical Storage Management......................................................................... 2-12
HD-WO – Fixed Content versus Optical Media ............................................................................. 2-13
Tools for administering the Archive Server.................................................................................... 2-14
Document Archiving....................................................................................................................... 2-15
Data Archiving................................................................................................................................ 2-16
Different kinds of document representation: CI, NCI ..................................................................... 2-17
Leading application ........................................................................................................................ 2-18
Leading application ........................................................................................................................ 2-19
3 Resources for Archive Server Administrators

Overview ........................................................................................................................................ 3-02
Global Services.............................................................................................................................. 3-03
Learning Services .......................................................................................................................... 3-04
Standard Support........................................................................................................................... 3-05
Premier Support Program.............................................................................................................. 3-06
Premier Support Program – Service Catalogue Options............................................................... 3-07
Application Support Program......................................................................................................... 3-08
Extended Hours Support ............................................................................................................... 3-09
Open Text Global Support Hotline................................................................................................. 3-10
OpenText Knowledge Center (KC) ................................................................................................ 3-11
Former IXOS Expert Service Center (ESC) .................................................................................. 3-12
Open Text Online Community ....................................................................................................... 3-13
Solution Packages by Open Text Global Services ........................................................................ 3-14
Overview Solution Packages ......................................................................................................... 3-15
4 Document Processing by the Archive Server

Document flow in the Archive – Synopsis ..................................................................................... 4-03
Document archival ......................................................................................................................... 4-04
Writing documents to IXW media (WORM or UDO)...................................................................... 4-05
Free space on a IXW volume ........................................................................................................ 4-06
Writing documents to ISO media to DVD (or WORM) (one Jukebox)........................................... 4-07
Table of Contents 0-3

Writing documents to ISO media to DVD (or WORM) (two Jukeboxes) ....................................... 4-08
Writing documents to ISO media to hard-disk based Storage System (HD-WO) ......................... 4-09
Writing documents to FS pool or VI pool (hard disk) ..................................................................... 4-10
Providing a document for read access .......................................................................................... 4-11
5 Document Structure on Storage Media

Inner structure of documents ......................................................................................................... 5-03
Directory structure on storage media ............................................................................................ 5-04
Files of documents......................................................................................................................... 5-05
System attributes in the ATTRIB.ATR ........................................................................................... 5-06
Tracing documents with dsClient (1) ............................................................................................. 5-07
Tracing documents with dsClient (2): document component details ............................................. 5-08
Document structure in the cache ................................................................................................... 5-09
Exercise: Examine a document on storage media ........................................................................ 5-10
6 IXW File system - WORM File system

IXW: The Open Text file system for UDO and WORM medias ..................................................... 6-03
How IXW medias are written ......................................................................................................... 6-04
WORM file system database ......................................................................................................... 6-05
IXW media finalization (1).............................................................................................................. 6-06
IXW media finalization (2): Properties ........................................................................................... 6-07
IXW medias and the ISO9660 filesystem standard ....................................................................... 6-08
7 Configuring Logical Archives

Chapter guide ................................................................................................................................ 7-02
Definition: logical archives ............................................................................................................. 7-03
Why use more than one logical archive?....................................................................................... 7-04
Restrictions for the number of logical archives.............................................................................. 7-05
Chapter guide ................................................................................................................................ 7-06
Inner structure of a logical archive................................................................................................. 7-07
Pool................................................................................................................................................ 7-08
Storage Systems supporting FS pools .......................................................................................... 7-09
Devices .......................................................................................................................................... 7-10
Chapter guide ................................................................................................................................ 7-11
Create an Original Archive (Logical Archive)................................................................................. 7-12
Create ISO (write-at-once) pool (1): Pool name and type ............................................................. 7-13
Create ISO (write-at-once) pool (2): Storage tier, Buffering, Writing, Backup............................... 7-14
Create ISO (write-at-once) pool (3): Scheduling write job ............................................................. 7-15
Use ISO pool with HD-WO (hard disk write-once) media (1) ........................................................ 7-16
Use ISO pool with HD-WO (hard disk write-once) media (2) ........................................................ 7-17
Create IXW (write-incremental) Pool ............................................................................................. 7-18
Create FS (single file) Pool............................................................................................................ 7-19
Create HDSK (write-through) pool................................................................................................. 7-20
Set document processing options (1) ............................................................................................ 7-21
Set document processing options (2) ............................................................................................ 7-22
Set security options (for HTTP access) ......................................................................................... 7-23
Exercise: Create logical archive with media pool on Archive Server ............................................ 7-24
8 Disk Buffer Configuration

Chapter guide ................................................................................................................................ 8-02
0-4 710-97
Disk buffer fundamentals ............................................................................................................... 8-03
Disk buffer purging......................................................................................................................... 8-04
Chapter guide ................................................................................................................................ 8-05
Disk buffer as temporary IXW media backup ................................................................................ 8-06
Ways of caching documents after writing to optical media............................................................ 8-07
Caching: in disk buffer or in cache? .............................................................................................. 8-08
Chapter guide ................................................................................................................................ 8-09
Purge configuration examples ....................................................................................................... 8-10
Chapter guide ................................................................................................................................ 8-11
Sizing considerations (1) ............................................................................................................... 8-12
Sizing considerations (2) ............................................................................................................... 8-13
Chapter guide ................................................................................................................................ 8-14
Create diskbuffer (1) ...................................................................................................................... 8-15
Create diskbuffer (2) – Provide hard disk partition ........................................................................ 8-16
Create diskbuffer (3) ...................................................................................................................... 8-17
Assign disk buffer to media pool.................................................................................................... 8-18
One or more disk buffers? ............................................................................................................. 8-19
Exercise: Create disk buffer........................................................................................................... 8-20
9 Document Processing Options

Chapter Overview .......................................................................................................................... 9-02
Compression.................................................................................................................................. 9-03
Encryption ...................................................................................................................................... 9-04
BLOBs (1) – Properties.................................................................................................................. 9-05
BLOBs (2) – Tracing documents with dsClient.............................................................................. 9-06
Single instance (1) – Properties..................................................................................................... 9-07
Single instance (2) – Tracing Single Instance components .......................................................... 9-08
Delayed archiving (1) – Concept ................................................................................................... 9-09
Delayed archiving (2) – pool _DELAYED_ .................................................................................... 9-10
Delayed archiving (3) – start archiving .......................................................................................... 9-11
Cache enabled............................................................................................................................... 9-12
Timestamps (1) – Properties ......................................................................................................... 9-13
Timestamps (2) – Signing a document.......................................................................................... 9-14
Timestamps (3) – Verifying a signed document ............................................................................ 9-15
Timestamps (4) – Renewal of Timestamps ................................................................................... 9-16
Timestamps (5) – Verification Modes ............................................................................................ 9-17
10 Document Lifecycle Management Overview

Document Lifecycle Management ............................................................................................... 10-02
Value of Records & Documents................................................................................................... 10-03
Retention Management Layers.................................................................................................... 10-04
Archive Server – Retention Handling .......................................................................................... 10-05
Retention Handling – Exterior View............................................................................................. 10-06
Retention period .......................................................................................................................... 10-07
Retention date.............................................................................................................................. 10-08
Protected documents................................................................................................................... 10-09
Example for Retention – Time based .......................................................................................... 10-10
Examples for Retention – Event & Time based........................................................................... 10-11
Deferred Archiving ....................................................................................................................... 10-12
Compliance Mode ........................................................................................................................ 10-13
Exercise: Retention Settings........................................................................................................ 10-14

11 ELS Architecture
Open Text Content Services (1) .................................................................................................. 11-02
Open Text Content Services (2) .................................................................................................. 11-03
Enterprise Library Services (1) .................................................................................................... 11-04
Enterprise Library Services (2) .................................................................................................... 11-05
Components of Enterprise Library Services ................................................................................ 11-06
Runtime & Core Services ............................................................................................................ 11-07
Open Text ECM 10 Architecture.................................................................................................. 11-08
Base Services .............................................................................................................................. 11-09
The inner workings ...................................................................................................................... 11-10
12 Archive Administration
Administration Tools – Overview ................................................................................................. 12-02
Administration Client, Web Services, Repositories ..................................................................... 12-03
Administration Client – GUI Overview ......................................................................................... 12-04
Administration & Monitoring......................................................................................................... 12-05
Where to find what – Archives, SAP, Security............................................................................. 12-06
Logical Archives (1) ..................................................................................................................... 12-07
Logical Archives (2) ..................................................................................................................... 12-08
Where to find what – Known Servers .......................................................................................... 12-09
Where to find what – Jobs, Scan Stations, Notifications ............................................................. 12-10
Events and Notifications .............................................................................................................. 12-11
Notify the Administrator in case of a problem.............................................................................. 12-12
Where to find what – Utilities ....................................................................................................... 12-13
Where to find what – Configuration Settings ............................................................................... 12-14
Track processes through Web Monitor........................................................................................ 12-15
MonitorServer and WebMonitor...................................................................................................12-16
Logging of Administration Client .................................................................................................. 12-17
13 Archive Server Startup and Shutdown

Components of Enterprise Library Services ................................................................................ 13-02
ELS Archive process layers......................................................................................................... 13-03
Different types of spawner shutdown .......................................................................................... 13-04
Startup and Shutdown on OS level (Windows) ........................................................................... 13-05
Checking status after startup (1): DS database operation .......................................................... 13-06
Checking status after startup (2): Spawner layer ........................................................................ 13-07
Runtime and Core Services in ELS Administration ..................................................................... 13-08
STORM caveats........................................................................................................................... 13-09
Exercise: Shut down and start up your Archive Server ............................................................... 13-10
14 Archive Server Monitoring

Chapter guide .............................................................................................................................. 14-02
Parameters observed by the Monitor Web Client........................................................................ 14-03
MonitorServer and WebMonitor...................................................................................................14-04
Review job messages and job protocol ....................................................................................... 14-05
Change Protocol Settings ............................................................................................................ 14-06
Chapter guide .............................................................................................................................. 14-07
Events and Notifications .............................................................................................................. 14-08
Notify the Administrator in case of a problem.............................................................................. 14-09
Scriptable monitoring (1): ixmonTest........................................................................................... 14-10
Scriptable monitoring (2): Scheduled jobs protocol ..................................................................... 14-11
0-6 710-97
15 Handling Optical Archive Media
Possible states of optical archive media...................................................................................... 15-02
Regular tasks when using ISO Medias........................................................................................ 15-03
Regular tasks when using IXW Medias ....................................................................................... 15-04
IXW media volume assignment to a pool .................................................................................... 15-05
IXW media naming scheme......................................................................................................... 15-06
Automatic IXW media initialization............................................................................................... 15-07
IXW media finalization (1): Properties ......................................................................................... 15-08
IXW media finalization (2): Usage ............................................................................................... 15-09
When the jukebox(es) are filled up .............................................................................................. 15-10
Re-inserting offline media into the jukebox on demand .............................................................. 15-11
16 Media Migration
Chapter guide .............................................................................................................................. 16-02
Introduction .................................................................................................................................. 16-03
Volume Migration – Process........................................................................................................ 16-04
Migration Server’s work ............................................................................................................... 16-05
Additional considerations............................................................................................................. 16-06
Chapter guide .............................................................................................................................. 16-07
Preparation steps – Create Migrate Volumes Job....................................................................... 16-08
Preparation steps – Create Migration Target Pool ...................................................................... 16-09
Plan migration for selected volumes............................................................................................ 16-10
Review migration progress of volumes........................................................................................ 16-11
Pause Migration Job .................................................................................................................... 16-12
After a migration project............................................................................................................... 16-13
Chapter guide .............................................................................................................................. 16-14
Verification after Migration (1)...................................................................................................... 16-15
Bulk migration of ISO images (1)................................................................................................. 16-18
Bulk migration of remote ISO volumes (1)................................................................................... 16-21
Bulk migration of remote ISO volumes (2)................................................................................... 16-22
Run Migration per Pool ................................................................................................................ 16-23
Exercise: Do media migration...................................................................................................... 16-24
17 Export and Import of Storage Media

Possible states of optical archive media...................................................................................... 17-02
Exporting a medium: when documents’ retention period has passed (1) ................................... 17-03
Exporting a medium: when documents’ retention period has passed (2) ................................... 17-04
Single-instance archiving (SIA) and media export....................................................................... 17-05
Steps for exporting a medium of a SIA-enabled archive ............................................................. 17-06
Importing a medium ..................................................................................................................... 17-07
Media Import & Index Reconstruction ......................................................................................... 17-08
Exercise: Export/ import a medium.............................................................................................. 17-09
18 Consistency Checks for Storage Media and Database

Consistency checks: overview..................................................................................................... 18-02
Check database against volume.................................................................................................. 18-03
Using consistency check tools..................................................................................................... 18-04

Check volume against database (1) ............................................................................................ 18-05
Check volume against database (2) ............................................................................................ 18-06
Check only volume ...................................................................................................................... 18-07
Check document.......................................................................................................................... 18-08
Compare backup IXW medias ..................................................................................................... 18-09
Exercise: Check and repair consistency between medium and database .................................. 18-10
19 Expanded Archive Server Installations

Chapter overview ......................................................................................................................... 19-02
Local Backup of Media ................................................................................................................ 19-03
Single Archive Server with separate backup jukebox ................................................................. 19-04
RemoteStandby ........................................................................................................................... 19-05
Architecture of Remote Standby (1) ............................................................................................ 19-06
Architecture of Remote Standby (2) ............................................................................................ 19-07
Switch over to remote standby ... ................................................................................................ 19-08
Scenarios for Remote Standby Server ........................................................................................ 19-09
HotStandby .................................................................................................................................. 19-10
Hot Standby Server with two hubs............................................................................................... 19-11
Hot Standby and Remote Standby Server .................................................................................. 19-12
Features of a Hot Standby Server ............................................................................................... 19-13
Cache Server ............................................................................................................................... 19-14
Cache Server Scenario................................................................................................................ 19-15
Cache Server ............................................................................................................................... 19-16
Input Scenario and Local Cache Server ...................................................................................... 19-17
Remote Standby Server versus Cache Server............................................................................ 19-18
Summary...................................................................................................................................... 19-19
20 Remote Standby Configuration and Operating

Chapter guide .............................................................................................................................. 20-02
Basic concept and benefits.......................................................................................................... 20-03
Proposal: central backup for multiple servers.............................................................................. 20-04
How replication is performed ....................................................................................................... 20-05
Chapter guide .............................................................................................................................. 20-06
Make original and Remote Standby servers known to each other .............................................. 20-07
Replicate External Archives......................................................................................................... 20-08
Replicate Diskbuffer..................................................................................................................... 20-09
Replicate WORM pool ................................................................................................................. 20-10
Replicate ISO pool ....................................................................................................................... 20-11
Chapter guide .............................................................................................................................. 20-12
The replication job ....................................................................................................................... 20-13
Replicated Volumes..................................................................................................................... 20-14
Exercise: Configure and perform RemoteStandby replication .................................................... 20-15
Chapter guide .............................................................................................................................. 20-16
EMC Centera: ISO Images - Remote standby ............................................................................ 20-17
EMC Centera: Single file - Remote standby................................................................................ 20-18
HDS DRU / HP XP: ISO – Remote Standby ............................................................................... 20-19
IBM DR550: single file & ISO – Remote standby ........................................................................ 20-20
NetApp Filer: single file & ISO – Remote standby....................................................................... 20-21
21 Setting up an Administrator Workstation

Requirements for an administrator’s workstation ........................................................................ 21-03
0-8 710-97
Installing the graphical administration tools................................................................................. 21-04
Additional considerations............................................................................................................. 21-05
22 Periodic Jobs
Tasks for jobs: synopsis (1) ......................................................................................................... 22-03
Tasks for jobs: synopsis (2) ......................................................................................................... 22-04
Running several jobs simultaneously .......................................................................................... 22-05
Scheduling automatic daily jobs: Example .................................................................................. 22-06
Jobs administration ...................................................................................................................... 22-07
Disable a Job ............................................................................................................................... 22-08
Edit a job (1): scheduling ............................................................................................................. 22-09
Edit a job (2): scheduling ............................................................................................................. 22-10
Edit a job (3): conditional invocation ............................................................................................ 22-11
Additional recurring tasks not executable as jobs ....................................................................... 22-12
Exercise: Schedule jobs appropriately ........................................................................................ 22-13
23 Configuring Audit Trails

Agenda......................................................................................................................................... 23-02
Audit Trails - Overview................................................................................................................. 23-03
Collect Audit Data ........................................................................................................................ 23-04
Access Audit Information – On Documents & Administrative Infos............................................. 23-05
Purge Audit Data – exportAudit Command ................................................................................. 23-06
Purge Audit Data – Periodic Job.................................................................................................. 23-07
Access Audit Information – On Single Document (1) .................................................................. 23-08
Access Audit Information – On Single Document (2) .................................................................. 23-09
Deletion Holds.............................................................................................................................. 23-10
Exercise: Audit Trails ................................................................................................................... 23-11
Exercise: Deletion Holds.............................................................................................................. 23-12
24 Backing up the Archive Server

Chapter guide .............................................................................................................................. 24-02
Which HD areas have to be mirrored (RAID 1 or RAID 5) .......................................................... 24-03
Chapter guide .............................................................................................................................. 24-04
ISO pool backup .......................................................................................................................... 24-05
IXW pool backup.......................................................................................................................... 24-06
Chapter guide .............................................................................................................................. 24-07
Which HD areas have to be backed up ....................................................................................... 24-08
FS & HDSK pool backup ............................................................................................................. 24-09
Disk buffer backup ....................................................................................................................... 24-10
Database backup......................................................................................................................... 24-11
STORM files backup (1): What has to be backed up .................................................................. 24-12
STORM files backup (2): Backup methods ................................................................................. 24-13
Software backup .......................................................................................................................... 24-14
25 Hard Disk Resource Maintenance

Disk buffer.................................................................................................................................... 25-03
Add hard disk volume to disk buffer ............................................................................................ 25-04
FS & HDSK pool .......................................................................................................................... 25-05
DocumentService Cache ............................................................................................................. 25-06
Create New Cache ...................................................................................................................... 25-07

Assign Cache to an Archive......................................................................................................... 25-08
Databases: DS, WORM filesystem.............................................................................................. 25-09
Other HD resources ..................................................................................................................... 25-10
Exercises ..................................................................................................................................... 25-11
26 Statistics and Accounting Information

Chapter guide .............................................................................................................................. 26-02
Read/write statistics for storage media........................................................................................ 26-03
Statistics about reading from cache / jukebox / hard disk ........................................................... 26-04
DS statistics: technical aspects ................................................................................................... 26-05
Chapter guide .............................................................................................................................. 26-06
Statistics for jukeboxes, drives, media ........................................................................................ 26-07
Structure of STORM statistics files .............................................................................................. 26-08
Statistics file processing .............................................................................................................. 26-09
Chapter guide .............................................................................................................................. 26-10
Access logging by Archive Server ............................................................................................... 26-11
Using retrieved accounting data for billing................................................................................... 26-12
Reorganization of “old” accounting data...................................................................................... 26-13
27 Logfiles and Loglevels

Chapter guide .............................................................................................................................. 27-02
Log message structure (1): General ............................................................................................ 27-03
Log message structure (2): STORM trace file ............................................................................. 27-04
Log message interrelations (1): Within a log file.......................................................................... 27-05
Log message interrelations (2): Across log files.......................................................................... 27-06
Chapter guide .............................................................................................................................. 27-07
Static vs. dynamic loglevel settings ............................................................................................. 27-08
Log switches (1)........................................................................................................................... 27-09
Log switches (2)........................................................................................................................... 27-10
STORM loglevels ......................................................................................................................... 27-11
Chapter guide .............................................................................................................................. 27-12
Size limitations for logfiles (general) ............................................................................................ 27-13
Size limitations for STORM log and trace files ............................................................................ 27-14
Chapter guide .............................................................................................................................. 27-15
Relevant logfiles for Archive Server Operations.......................................................................... 27-16
Logging: Further sources of information...................................................................................... 27-17
28 Summary of troubleshooting tasks on Archive Server

Avoiding problems ....................................................................................................................... 28-03
Symptom examination (1): Error state (“red bulb”) in Server Monitor ......................................... 28-04
Symptom examination (2): “Dead” services in spawncmd status................................................ 28-05
Symptom examination (3): Red bulb in Archive Server job protocol ........................................... 28-06
Symptom examination (4): DocumentPipeline errors .................................................................. 28-07
Further Information ...................................................................................................................... 28-08
Contacting Customer Support ..................................................................................................... 28-09
Appendix A Exercise Worksheets
0-10 710-97
Exercise 1: Storing and retrieving a sample document.........................................................A-03
Exercise 2: Using the Knowledge Center ..............................................................................A-04
Exercise 3: Writing stored documents to WORM ..................................................................A-05
Exercise 4: Examine a document on storage media .............................................................A-06
Exercise 5: Finalizing a WORM.............................................................................................A-07
Exercise 6: Create logical archive on Archive Server ...........................................................A-08
Exercise 7: Create disk buffer ...............................................................................................A-10
Exercise 8: Store and examine a document in a BLOB ........................................................A-11
Exercise 9: Store and examine a single-instance archived document..................................A-12
Exercise 10: Retention Settings ............................................................................................A-13
Exercise 11: Archive Server components .............................................................................A-14
Exercise 12: Check operating condition and restart Archive Server cleanly.........................A-15
Exercise 13: Archive Server monitoring ................................................................................A-16
Exercise 14: WORM operating ..............................................................................................A-17
Exercise 15: Volume migration..............................................................................................A-18
Exercise 16: Volume export and import ................................................................................A-19
Exercise 17: Check consistency of storage volume and database .......................................A-20
Exercise 18: Remote Standby configuration and operating ..................................................A-21
Exercise 19: Scheduling periodic jobs...................................................................................A-22
Exercise 20: Audit Trails........................................................................................................A-23
Exercise 21: Deletion Holds ..................................................................................................A-25
Exercise 22: Online backup of WORM filesystem database.................................................A-26
Exercise 23: Add partition to disk buffer................................................................................A-27
Exercise 24: Move DocumentPipeline directory....................................................................A-28
Appendix B Archive Server – Command Line Tools

0. General Remarks ..................................................................................................................B-01
1. dsClient..................................................................................................................................B-01
2. spawncmd..............................................................................................................................B-03
3. dpctrl ......................................................................................................................................B-03
4. ixmonTest / ixmontst (Windows)............................................................................................B-04
5. cdadm ....................................................................................................................................B-04
Appendix C Glossary

0-12 710-97
1 Course Objectives and Contents
Slide 1
Learning Services • August 31, 2009 • Copyright © Open Text Corporation. All rights reserved.
Course Objectives and Contents 1-1

710 - Course objectives
Gain a basic understanding of the Archive Server

Role within the Open Text / IXOS Solutions
Functionality and architecture
Be able to administer an Archive Server efficiently and reliably

This includes being able to
configure the Archive Server according to the enterprise’s needs
operate the server reliably
detect and solve common problems yourself
Course Objectives and Contents • Slide 2

1-2 710-97
710 - Contents overview
Introduction
Introduction Administration
Administration Tasks
Tasks
Archiving
Archiving with
with Open
Open Text
Text Solutions
Solutions Server
Server startup
startup and
and shutdown
shutdown
Collaborating Monitoring
Monitoring for
for problems
problems
Collaborating with
with Open
Open Text
Text
Operating
Operating optical
optical media
media
Media
Media migration,
migration, export,
export, and
and import
import
Document
Document processing
processing by
by the
the Backup concepts
Backup concepts
Archive Server
Archive Server Further
Further configuration
configuration tasks
tasks
Stages
Stages of
of document
document processing
processing Auditing
Auditing and
and statistics
statistics
Document
Document structure on storage
structure on storage media
media
Security
Security aspects
aspects
Archive
Archive Server
Server basis
basis configuration
configuration Interfaces
Interfaces and
and protocols
protocols
Logical
Logical archives,
archives, media
media pools
pools Configuring
Configuring HTTP
HTTP security
security
Disk
Disk buffers
buffers Users
Users and
and permissions
permissions
Troubleshooting
Troubleshooting
Archive
Archive Server
Server architecture
architecture Working
Working with
with logfiles
logfiles
Functional
Functional components
components Tracing
Tracing documents
documents
Navigating
Navigating through
through the
the server
server Problem
Problem investigation
investigation and
and prevention
prevention
Typical
Typical problems
problems

Course Objectives and Contents 1-3

Where to go from here
710
710 715
715
See
See
Archive Server Archive Server
http://opentext.com/training Administration Advanced Admin
http://opentext.com/training
for
formore
moreinformation
informationonon 5 days 3 days
Learning
LearningServices
Servicesoffering.
offering.
953
953
Archive Server
725
725 Installation
Scanning Documents 4 days
with Enterprise Scan
727
727
1 day
Archive Clients
User
760
760 Administration
workshop SAP Document
740
740 Archiving Customizing 2 days
AS-SEC
AS-SEC
Exchange Archive Server
5 days
Administration AS-STO
AS-STO
Security Workshop
3 days Storage Systems

Workshop
Application-specific
administration courses
Special Archive Server

Application-specific workshops
customizing courses
Starting from the present course 710, Archive Server Administration, Open Text Learning Services
offers a variety of courses for different education needs.
• Since course 710 covers the server part of an Livelink Enterprise Archive only, it is
recommended for all administrators to complete their Administration skills with the
application-specific counterpart. For this purpose, Learning Services offers administration
courses for all Livelink Enterprise Archive products separately; all of them require having
attended course 710 before.
• 715 Archive Server Administration Advanced is not needed for administering a “normal”
Archive system. Target group of this course are administrators of huge Archive installations,
especially in outsourcing centers; here they learn how to automate administrative tasks,
integrate the Archive Server into a computing center infrastructure more tightly, and do
advanced troubleshooting.
• Some of the leading systems, e. g. SAP, require additional customizing or configuration in
order to integrate optical document storage into their “main” functionality. Learning Services
offers appropriate, product-specific customizing courses for building up the necessary skills.
• For specialized interest, further courses and workshops are available. For full information
including scheduled course dates, see http://www.opentext.com/training
1-4 710-97
2 Archiving with Open Text
A general introduction
Slide 1
Archiving with Open Text 2-1

Chapter overview
Archiving: Fundamental properties

Introduction to the Archive Server
Types of document/data archiving
The role of the “leading application”
Archiving with Open Text • Slide 2

2-2 710-97
Fundamental Aspects of Archiving
Certain business scenarios require that documents & data ...

can no longer be changed or manipulated
i. e. optical media
i. e. write-once mode on hard-disk based storage system
– or proof by use of time stamps that content has not been modified
can be retrieved as needed

It is stored safely (i. e. protected against becoming lost or changed)
throughout its retention period
It can be found easily (in the leading application)
It is available for prompt retrieval and display
For a scanned document:

Ensure it is a legally correct facsimile of the original document

Traditionally, optical media like DVD or WORM have been used to ensure that documents are no
longer changed or manipulated. Modern storage systems can usually be switched to "write-once
mode" to ensure that documents cannot be changed even though hard-disk is used as final
storage media. While non-manipulation of documents is desirable, disposition management
(removing documents after their retention period has expired should also be considered.
Besides technical components, the right organisational implementation and its documentation are
important for ensuring legally compliant archiving according to the specific lawmakers.

Archive Server
Archive Server
Information Management Management Services
- Management due to business process
- Handling structured documents - Configuration
- Group into logical archives - Customization
- Document Lifecycle Management - Monitoring & Analysis
- Retention periods & audit trails - Administration:
- Processes
Storage Optimization - Tasks
- Virtualization of storage systems - Schedules
- Automation of processes / tasks - Monitoring
- Backup, migration, … - Policies
- Encryption
- Compression
Storage Resource Handling

- Support of different storage systems
SCSI, IP, FC, devices, drives, robots
- Hide physical properties
- Handle container files

2-4 710-97
Storage technologies
used by Archive Server
CAS storage systems (i. e. EMC Centera)

"Virtual jukebox" writing ISO images
Storing single files
SAN/NAS storage systems (i. e. NetApp, HDS, STK …)

depending on system, ISO images/single files
Hard disk partitions or HSM storage systems

For short-term archiving (e. g. employment applications)
Jukeboxes with Optical media (i. e. DVD, WORM, UDO)

Guarantees against corruption, changes, or loss of documents
Inexpensive media for large quantities of data

About the media type abbreviations:

• CAS = Content Addressed Storage
• SAN = Storage Area Network
• NAS = Network Addressed Storage
• UDO = Ultra Density Optical
Abbreviations and related storage technologies will be covered in the next slides in more detail.

Supported Storage Platforms
Leading Application
Archive Server
Single Documents Container Files: ISO Images
Local Buffered Write (secure & reliable through Disk Buffer)

Hard disk
(test systems only) WO Feature WO Feature
Retention Periods Retention Periods
HP FSE NetApp HP FSE NetApp filer

UDO WORM
GRAU SnapLock GRAU SnapLock
IBM System Storage IBM System Storage

N series N series
IBM SSAM
EMC Centera WORM EMC Centera DR550 DVD
Sun NAS53X0 Sun NAS53X0

SAM-FS/WORM-FS SAM-FS/WORM-FS
HDS HCAP HDS HCAP
Always check the Release Notes Storage Systems (KC) for the most recent status.
For details on supported operating systems and interface view the storage platform release notes.
WO Feature
The write-once feature allows i.e. hard-disk based storage systems to store documents and data
on the hard-disk similar to e.g. a DVD-R. After the inital write process, the data is stored as "read-
only" and may only be modified or deleted after a certain retention period.
2-6 710-97
Opticals – DVD, WORM, UDO
Archive Server Support of various jukebox vendors

Support of different media:
WORM, UDO
– Single file
– ISO image (WORM media only)
DVD
– ISO image
Connection:
Advantage
SCSI or
fibre channel Support of offline media
Non erasable, robust
Tamper proof
Drawback
Nearline media
Optical jukeboxes:
DVD, WORM, UDO
Cache areas required for fast access


Comparison of Optical Media Types
UDO is similar to standard WORMs

same size, significantly higher storage capacity
CD media not supported anymore ≥≥ 99.7

.7
WORM
WORM
Written
Written incrementally
incrementally
Proprietary
Proprietary filefile system
system
or
or one disk side written
one disk side written
in
in aa single
single action
action asas
DVD-R
DVD-R ISO
ISO 9660
9660 file
file system
system
Single
Single oror double-sided
double-sided Capacity ≈≈ 9.2
Capacity 9.2 GBGB
CD-R
CD-R One
One disk
disk side
side written
written
in
in aa single
single action
action UDO
UDO
ISO
ISO 9660
9660 file
file system
system Written
Written incrementally
incrementally
Capacity ≈≈ 4.3
Capacity 4.3 GB
GB // side
side Proprietary
Proprietary file
file system
system
Capacity ≈
Capacity ≈ 30 GB
30 GB

About the media type abbreviations:

• WORM = Write Once, Read Multiple
• CD-R = not supported any longer!
• DVD-R = Digital Versatile Disk Recordable
• UDO = Ultra Density Optical
In general, a DVD must be written at one time. It cannot be modified thereafter. Backup DVD
copies are identical in every way to the original medium and should be stored in a separate
location.
WORM disks can only be written once, but the disk itself can be written incrementally.
MO disks (“magneto-optical”) are the re-writable counterparts of WORMs. Since they do not fulfill
the legal requirement of unalterability of stored data, OT does not support the use of MOs as
storage media.
As opposed to magnetic storage media, particularly tapes, optical disks offer excellent long-term
safety of data. When archiving documents, the fact that data cannot be modified is also an
important advantage to fulfill legal requirements.
UDO is a fairly new media, similar to standard WORMs, also in size, but with a significantly higher
storage capacity. See also http://www.udo.com
If desired, non-optical media (like hard disk partitions) can be used as alternative storage
technology. This serves mainly these purposes:
• Documents can be deleted easily; this may be necessary under certain legal circumstances,
e. g. when storing job application documents.
• Access to documents stored on hard disks is always very fast and does not impose any
workload on the optical storage devices. Situations exist where this is an important
requirement, e. g. when using documents with overlay forms.
2-8 710-97
CAS – Content Addressed Storage –
Example: EMC Centera
Archive Server Support of WO (write-once) feature
Support of retention periods

CentraStar Retention period on single document or
Retention period per virtual jukebox
DS/STORM Network connection (IP)
Centera SDK
Single
documents
Advantage:
ISO image: easy backup to optical media
IP connection Flexible partition size
Drawback
Centera SDK used
Virtual Jukebox N
Can’t be used as disk subsystem
No file system available
Centera SDK is provided by OpenText.

SAN – Storage Area Network –
Example: Hitachi Data Retention Manager
Support of WO (write-once) feature

Archive Server
Support of retention periods
Use as normal Retention period per virtual jukebox
file system for
OS, DB, .. Storage LDEVs integrated as one or
more virtual jukeboxes
Data stored as ISO Image
STORM
HDS API: rmlib Fiber Channel connection
Advantage:
Easy backup to optical media
Can be used as disk subsystem
Virtual Jukebox
ISO images Deletion tool available by HDS
Drawback
API necessary
API is provided by HDS.
2-10 710-97
NAS – Network Adressed Storage –
Example: NetApp NearStore (SnapLock)
Integration into Document Service
Archive Server SnapLock enables Write-Once

feature on NearStore filers
Document Service
Support of fixed content for single
Disk Buffer documents
STORM (cfs devices) Support of ISO images
pool:
Single File pool: Treated as hard disk partition
(FS) Write-At-Once
libnetapp Provide large hard disk storage by
(ISO)
attaching multiples NetApp volumes
NetApp Storage System
Advantage
No special API necessary
Can be used together with optical
Single Files ISO files
and other storage media


NAS – HSM –
Hierarchical Storage Management
Container files (ISO image)

STORM API – HSM device
Archive Server
Support of virtual jukeboxes
Document Service
Retention periods in ISO image
Disk Buffer
Single documents
STORM (cfs devices)
pool: DS through disk buffer
Single File pool:
(FS) Write-At-Once
library
(ISO)
Hint:
HSM Release to tape not supported
always copy on hard disk required
Single Files ISO files

HSM is policy-based management of file backup and archiving in a way that uses storage devices
economically and without the user needing to be aware of when files are being retrieved from
backup storage media.
Although HSM can be implemented on a standalone system, it is more frequently used in the
distributed network of an enterprise. The hierarchy represents different types of storage media,
such as redundant array of independent disk systems, optical storage, or tape, each type
representing a different level of cost and speed of retrieval when access is needed.
For example, as a file ages in an archive, it can be automatically moved to a slower but less
expensive form of storage. Using an HSM product, an administrator can establish and state
guidelines for how often different kinds of files are to be copied to a backup storage device. Once
the guideline has been set up, the HSM software manages everything automatically.
HSM adds to archiving and file protection for disaster recovery the capability to manage storage
devices efficiently, especially in large-scale user environments where storage costs can mount
rapidly.
An administrator can set high and low thresholds for hard disk capacity that HSM software will use
to decide when to migrate older or less-frequently used files to another medium. Certain file types,
such as executable files (programs), can be excluded from those to be migrated. For connection
with the Archive Server, these thresholds should be set appropriately so that files stay on hard
disk.
2-12 710-97
HD-WO – Fixed Content versus
Optical Media
Magnetic storage media: Optical media:

Various storage vendors WORM, DVD, UDO
High volume storage Written and read by a laser
Sometimes already existing as file Data stability
servers (NetApp) or backup system
(HSM) Tamper proof (no manipulation)
Improved technique for fast access Non erasable, robust
Additional security by Medium access time
software technique
(if volume in drive)
Can be destroyed by magnetic fields
or water leakage DVD:
widely used in consumer market
Dust (media)
mechanical wear out (jukeboxes)

Incremental write for DVD-R

• Not supported
Support of DVD-RAM as Soft-WORM (also known as DVD-WO)

• Lot of blocks are wasted when writing FCBs.
• Incompatibilities in read drives have been found.
• DVD-RAM not been standardized by DVD-forum.
DVD-RAM in the MO modus

• Project solution
• Not allowed to use!

Tools for administering the
Archive Server
Graphical administration tools

Archive Server Administration
– Configuring the server
– Handling jukeboxes and optical media
Document Pipeline Info
– Monitoring and troubleshooting the Document Pipeline
Web Monitor
Command line tools

Gathering storage statistics
Administering the system without graphical screen
Low-level system handling for troubleshooting

The graphical administration tools are focused on “everyday” server handling. Nevertheless,
most system configuration tasks can be accomplished with them as well. These tools are
normally installed on the administrator’s own workstation computer, enabling him to
administer the Archive Server remotely. This also includes the WebMonitor available via a
web browser.
Command line tools on the Archive Server grant the administrator “deeper” access to the
server than the graphical tools provide. This is normally reserved for special occasions like
advanced troubleshooting or — for example — specific data migration tasks.
2-14 710-97
Document Archiving
Paper documents
Scanning client
Document
Scanning retrieval
Archive Server
Archiving
image files
Machine-generated
documents
Server of
Direct archiving Download
leading
via specific interface
application
(e. g. SAP)
Display on client
Documents from
external sources Batch input
via file system

Regarding the archival of documents, three basic variants can be distinguished.

Paper documents are scanned first; this is normally done using the scanning application
Livelink Enterprise Scan. The resulting image files are then transferred to the Archive
Server for archival.
Machine-generated documents can be archived directly from the generating server to the
Archive Server via a specialized interface — provided that such an interface exists for that
application system. The “classical” example for this type of archival is archiving from SAP
(outgoing documents and print lists).
Document files from external sources are archived via the so-called batch input interface of
the Archive Server . This is the most generalized way of archiving: The documents may
origin from any leading application — there is no special integration interface necessary.
Moreover, scanned images of paper documents can be archived that way as well as
machine-generated documents.
Document retrieval is carried out the same way, no matter how the documents have entered the
archive (as detailed above): The retrieval client component downloads the document from the
Archive Server to the user’s workstation, then the document is displayed in a suitable viewing
application (for most frequently used document formats, this is the Archive Windows Viewer).

Data Archiving
User workstations
Server of leading application

E. g. SAP
E. g. MS Exchange
Direct archiving Retrieval by application server
Archive Server

Compared to document archiving (see previous page), data archiving implies different roles of the
leading system and the Archive Server.
A typical server-based application produces and/or stores large amounts of electronic data.
However, the available storage space for that application data is limited by the server hardware. In
many cases, the server is not even able to keep all data it is supposed to due to business
requirements (e. g. a certain legally in forced data retention period). In such a situation, selected
application data can be sourced out from the application server to the Archive Server ; this is
referred to as data archiving.
The application server can then access the archived data again for various kinds of processing;
this includes:
• Display of archived data items (in non-changeable mode)
• Reloading archived data into the server’s own storage space
From the point of view of the leading application, the Archive Server is therefore a mere (safe and
huge) storage backend. As a consequence, the system users (and their computers) have no direct
relation or connection to the Archive Server ; they only “see” the leading application’s server that
interacts with the Archive Server behind the scenes.
The following Open Text solutions make use of the Archive Server the data archiving way:
• Data Archiving for SAP Solutions
• Email Archiving for MS Exchange
• Email Archiving for SAP Solutions
2-16 710-97
Different kinds of document representation: CI, NCI
Non-coded information — NCI Coded information — CI

Documents stored in non-text formats, Machine-generated, machine-readable
e. g. image data documents
Machine does not know wording of
document
Automatic indexing not possible Automatic indexing possible
However, OCR may be used for this Depending on application context
Examples of NCI documents: Examples of CI documents:

All scanned documents Print lists, voucher lists
Incoming faxes Outgoing documents from SAP R/3
Office documents
E-mail messages
“Image” “Text”

Non-coded information (also referred to as NCI):

• Contents of a document captured as an image of the original paper document; this occurs
when paper documents are scanned
• Archived as an image
• Retrieved and displayed as an electronic facsimile of the scanned-in document
• Contents cannot be interpreted by a computer (unless optical character recognition, OCR, is
performed). Consequently, TIFF documents cannot be ‘searched’ for keywords
• It may be desirable to have applications convert documents to TIFF format before archiving.
This protects against having their content modified afterwards and assures that the
document can be accessed and read in the future (regardless of what radical changes are
made to the software with which the document was originally produced)
Coded information (also referred to as CI):

• Computer-generated documents
• Machine-readable
• Archived in its original form
• Can be searched for indices (similar to keywords)

Leading application
The leading application …

controls how documents are used
stores references to archived documents for retrieval
Expressed as document IDs
maintains the relationship between documents and business-related

“objects”, e. g.
business occurrences like purchase orders, deliveries, …
attribute sets within a document index
uses a communication interface to the Archive Server

(and/or the Archive Clients)

For making up an optical archiving solution, it is not sufficient just to store documents or document
images on storage media. In order to make the documents serve some business purpose, they
must be made available for retrieval by one of these methods:
• Maintaining attributes for each document by which document users can search for specific
documents of interest. Such attributes can include:
– Date of origin
– Document number
– Customer number
– Document type: order, invoice, correspondence, …
– … and many more
• Linking documents to some kind of “object” maintained by another business data system.
For example, an invoice document may correspond to an invoice booking in the SAP
database. A SAP user can search for and retrieve the invoice booking, then retrieve the
corresponding document by activating a link to it that is stored as part of the booking data.
Since the choice of how to make documents retrievable fundamentally decides how documents are
used in business, the system performing this task is called the leading application. Depending on
the solution, this may be an i.e. Email Server, SAP or Livelink.
2-18 710-97
Leading application
Order No. 6348
linked to ID aaahx4c...
ID aaahx4c...
requests ID aaahx4c...
requests
Order No. 6348
Leading Application Archive Server

User
The leading application …

controls how documents are used
stores references to archived documents for retrieval
Expressed as document IDs, i. e.
maintains the relationship between documents and business-related “objects”,
e. g.
business occurrences like purchase orders, deliveries, …
attribute sets within a document index
uses a communication interface to the Archive Server
(and/or the Archive Clients)

2-20 710-97
3 Resources for Archive Server
Administrators
Slide 1
Resources for Archive Server Administrators 3-1

Overview
Global Services
Learning Services
Customer & Premier Support
Web Resources (KC)
Open Text Online Community
Solution Packages
Resources for Archive Server Administrators • Slide 2

3-2 710-97
Global Services
Objectives:
Helping customers to fully exploit the potential of
OpenText solutions, i.e.
Document and Data Archiving
Workflow Integration
Web-based Portals
Migration and parallel legacy and SAP systems
Existing archive migration
Implementing specialized archiving solutions on customers’ demand

Individual archiving projects
Solution packages

Solution packages are implementations for specialized archiving requirements. They are not
part of the standard products but can be added to them in order to expand their functionality.
Some solution packages are ready-to-run, others require a certain amount of consulting to be
established at a customer.
Cooperation with Global Services is initiated via your local sales representative; please contact
them for further details.

Learning Services
Course portfolio examples:

Consultant courses
See
Seehttp://www.opentext.com/training
http://www.opentext.com/training
601 ECM Fundamentals for
forfull
fullportfolio
portfolio
775 SAP Legal Compliance and
and courseschedule
course schedule
Administrator courses
710 Archive Server Administration
715 Archive Server Advanced Administration
Installation course
720 Archive Server Installation
Workshops
725 Scanning Documents
SAP-CST-PLCustomizing SAP Print Lists for Archiving
Customer-specific, on-site courses

OpenText’s training center Learning Services offers a wide variety of courses for different
OpenText and IXOS products and target groups; examples are given above.
Please check our webpage to see to contact your local Open Text training registrar:
http://www.opentext.com/training/contacts.html
3-4 710-97
Standard Support
Software Maintenance
Program (Standard Support) Global Services
Support Services Customers
Phone, Web, E-mail

Only for Standard Products
Software Updates
Customer Care Program
e-Newsletters
LiveLinkUp Webinar Series
Champion Toolkit
Open Text Online Accounts

Knowledge Center
Open Text Communities
Customer Self-Service


Premier Support Program
Dedicated Open Text Contact

Program Manager Global Services
Technical Specialist Customers
Site Inventory & Health Check

Knowledge of Customer Infrastructure
& Process
On-site Support
Many Optional Services
For more information, contact

TechnicalServicesNA@OpenText.com (North
America)
TechnicalServicesEMEA@OpenText.com
(EMEA)

The Premier Support Program is an optional support service that is offered in addition to the
Software Maintenance Program.
It provides you with a level of support that brings together highly experienced Technical
Specialists who will work with your in-house Service Management teams to assist with these
challenges and further the achievement of your deployment goals.
Benefits:
– Optimized Customer Support Processes
– Improved Understanding of Open Text Software
– Improved Risk Management
– Improved Strategic Planning
– Improved Issue Support
– Proactive Services
All of the services delivered by the Technical Services team are developed and delivered
within the ITIL framework. All members of the Technical Services team are ITIL certified.
Program Manager
The Program Manager is your single point of contact within Open Text Customer Support,
responsible for the relationship and all communication between your Service Management
Team and Open Text Customer Support/Development. They are also responsible for the
management of the delivery of the program to which you subscribe.
Technical Specialist
A Technical Specialist is responsible for working with the Program Manager and your Service
Management Team to manage the technical scope of the program to which you subscribe.
Their repsonsibilities depend on the Service Catalog options selected.
3-6 710-97
Premier Support Program –
Service Catalogue Options
Various Service Catalogue options can be delivered as part of your

Premier Support Program, i.e.:
– On-Site Support
– After-Hours Standby Support
– Critical On-Site Support
– Production Support
– Technical Administration
– Performance Check
– Health Check
– Capacity Planning
– Monitoring
– Security Audit
– Backup/Recovery and Failover Management
– SLA Consulting
See also
http://opentext.com/services/premier-support.html
On-site Support: A Technical Specialist is scheduled to travel to your site to provide

troubleshooting or configuration assistance.
After-Hours Standby Support: A Technical Specialist is scheduled for after-hours or weekend
standby assistance to provide a safety net during major changes.
Critical On-Site Support: A Technical Specialist is made available to go on-site to your location
the next business day to provide critical issue troubleshooting and resolution.
Production Support: A Technical Specialist assists during the final stage of an installation,
upgrade or functional expansion of your environment.
Technical Administration: A Technical Specialist provides daily technical administration of your
Open Text application on a full-time on-site basis. You may also be able to receive off-site or
part-time administration if remote access is available to the application.
Performance Check: The diagnosis of existing performance issues and the proactive
identification of potential performance bottlenecks before they negatively impact end-users’
experiences with the Open Text software system.
Health Check: The proactive identification of potential problems in the configuration and usage
of the Open Text software environment.
Capacity Planning: The continuous recording, statistical analysis and then prediction of the
future system's usage of technical resources (hardware, software, and network).
Monitoring: The real time monitoring of your system so that issues that arise can be verified
and corrected quickly.
Security Audit: The proactive identification of potential security problems in the configuration
and usage of thebasic Open Text software environment.
Backup/Recovery and Failover Management: The definition, implementation, and follow-on
support of a Backup/Recovery and Failover strategy.
SLA Consulting: Open Text can support you with the definition and implementation of a
Service Level Agreement (SLA).
See also http://opentext.com/services/premier-support.html
Application Support Program
Application Support
In addition to Premier Support Global Services
Support for specific applications Customers
Support for Customizing

Hotline support
Critical on-site support
Knowledge of Customizing
Code & Configuration

3-8 710-97
Extended Hours Support
24x7 Support for Critical Issues

24x5 Support for all Critical, Serious Global Services
and Normal Issues Customers
"Follow the Sun" Support for Serious

and Critical Issues


Open Text Global Support Hotline
Support Center – North America

Support Center – Germany
Support Center – UK
Support Center – APAC (Australia & Japan)
For more information, hours and phone numbers see

http://support.opentext.com

Standard support is provided during business hours (see

http://support.opentext.com for deails). Additionally, 24x7 support
is available.
3-10 710-97
OpenText Knowledge Center (KC)
Your portal for all Open Text

related product information
Access via:
http://knowledge.opentext.com
Find there:
Manuals
Release Notes
– Compatibility information
Installation/upgrade guides
Patches
Troubleshooting help
– Notes on specific
problem issues
– Troubleshooting guides

To get your own personal account, send an email to support@opentext.com with the
following information:
"Request for New Support Account"

First Name:
Last Name:
Email Address:
Phone Number:
Company Name:
Additional Information (if known):
Name of a co-worker who has KC access:
End User Code or Site ID:
Product Line(s):

Former IXOS Expert Service Center (ESC)
All ESC content has been moved to the

Knowledge Center (KC): see http://knowledge.opentext.com

Historically, archive related knowledge entries were found in the ESC. Contents have now
been migrated to the Knowledge Center (KC).
3-12 710-97
Open Text Online Community
Access via: http://communities.opentext.com

Open Text Online (OTO) is a business environment that serves your need to get the most out
of your Open Text products. The communities allow you to learn about best practices, ask
questions in forums and allow customers to share their experience.

Solution Packages by
Open Text Global Services
Expand functionality of Open Text products

Developed and offered by Open Text Global Services
Need to be purchased separately by customer
not included in maintenance contract
Maintenance/guarantee provided by Global Services

3-14 710-97
Overview Solution Packages
Packages Description
Insight Statistical evaluation of archived documents
Remote Cache Control Push documents to Archive Cache Server according to defined
rules
Precache Push documents to local cache
Volume Management Auto initialize hard disk volumes and control growth
Tool
Centera Delete Cleaning-up ISO images on EMC Centera
Media Check Check optical media on jukeboxes
Sync Check Comparison of two Archive Servers

(DB and binary comparison of documents)
verifyDoc Verification of already archived documents concerning
completeness and consistency

Contact your Global Services Consultant for more information on solution packages that you
are interested in.

3-16 710-97
4 Document Processing by the
Archive Server
How the Archive manages storage
and retrieval of documents
Slide 1
Document Processing by the Archive Server 4-1

Chapter overview
How the Archive handles documents during …

archiving
writing to media
retrieving
Document Processing by the Archive Server • Slide 2

4-2 710-97
Document flow in the Archive – Synopsis
Archival
Archive
Writing to Server Storage data- Storage Manager
storage base DS STORM
media
Retrieval WORM
file system
Document sources
Document Document Service

Pipeline
Disk buffer
Temp
IXW pool
Cache
Retrieval
Burn ISO pool
buffer
FS pool
HDSK VI pool
pool

The chart above gives a complete overview of the possible paths a document may take as it is processed by
the Document Processing by the Archive Server. The illustration also reveals that the whole “life cycle” of a
document is composed of three stages:
• The archival of the document from its source to either the disk buffer or a hard disk pool. In some
situations, documents pass the DocumentPipeline before they enter the Document Processing by the
Archive Server’s core component, the DocumentService.
An important aspect of this is that a document is defined to be archived already while it is still held in
the disk buffer, actually before it is stored on optical media or buffered disk. While this can be
interpreted as a potential safety gap (data is less safe in a hard-disk based buffer than on optical
disks), it is a mandatory precondition for many archiving applications requiring access to documents
immediately after their storage: The disk buffer provides this feature.
• Writing the document from the disk buffer to an optical medium or a buffered hard disk
Exception: Documents that have been stored in a write-through hard disk (= HDSK pool).
• Retrieving the document from its current storage location to a client.
The chart also already names the Document Processing by the Archive Server components that perform the
involved tasks:
• The DocumentPipeline preprocesses certain documents before they are stored.
• The DocumentService manages the buffering, optical storage, and retrieval of documents.
• The storage database DS is used by the DocumentService for storing technical attributes of stored
documents; they are needed to keep track of the current state of a document and to find it upon
retrieval requests.
• The StorageManager (also called STORM) manages optical media in jukeboxes and provides write
and read access to storage systems.
Details about all three mentioned document processing stages are explained on the following pages.

Document archival
Archive Server
Storage database DS
Document Pipeline
B Document tools D
Document sources
Document Service
Disk buffer
HDSK pool

The chart above illustrates the steps the Document Processing by the Archive Servertakes when a
it receives a document for archival:
(A) The document is stored as a file (or a set of files) in the DocumentPipeline directory.
This does, however, not apply to all documents. Depending on the leading application and
the used storage scenario, a document may as well bypass the DocumentPipeline and
directly enter the DocumentService where step (C) is performed.
(B) The DocumentPipeline preprocesses the document: A sequence of document tools (also
called DocTools) accesses the document one after the other and performs various tasks.
The exact sequence of steps depends again on the type of document and the storage
scenario. Examples of preprocessing actions include:
– Extracting attributes from the document’s contents
– Storing retrieved attributes in an index database of the leading application
– Adding information (example: a page index for a print list)
– Converting the document (example: collecting multiple scanned document pages into
a single multi-page image file)
(C) After the DocumentPipeline has finished its work — or when it has been bypassed — the
document is then handed over to the DocumentService. Depending on the archive
configuration, the document is stored in one of two places:
– If the document shall later be written to an optical medium, it is stored in a disk
buffer.
– If it shall be stored on a hard disk permanently, it is directly written to the destination
hard disk pool.
(D) The DocumentService stored status information about the received document in the storage
database; this includes the newly allocated document ID and the chosen storage location.
4-4 710-97
Writing documents to IXW media
(WORM or UDO)
Archive Server
Storage database DS
Storage Manager STORM
WORM
Document Service file system
Temp Original Backup
Write job Backup job
(optional)
Disk buffer Cache
Purge buffer job

The chart above illustrates the steps involved in writing documents from the disk buffer to IXW media. As
opposed to ISO media writing (detailed on the previous page), there are three separate periodic jobs
involved. They are invoked by the job schedule independently from each other, but the corresponding
actions on a specific document are always carried out in the order explained here.
IXW write job. The write job copies document files from the disk buffer to the target IXW media one
by one. (Unlike writing to ISO media, no ISO image preparation is involved). This involves the
following subtasks for each written file:
– The file is copied temporarily to another hard disk area.
– The file is copied from there to the IXW media.
– The file is read back from the IXW media and compared with the temporarily stored file
instance in order to ensure no writing errors have occurred. (If writing has failed, another
attempt is made to write the file.)
– The WORM filesystem database is updated so that it now knows the written file.
– The storage database DS is informed that the file is now resident on the IXW media.
The write job is usually scheduled to run rather often, e. g. every 30 minutes.
Backup job. Since writing to IXW media is comparatively slow, the IXW media write job never copies
documents to the IXW media backup itself; this task is left to the backup job that is normally executed
once a night. This job copies newly written data from all IXW medias to their corresponding backups;
it does this on filesystem block level rather than on file level which makes the process faster. After
this, original and backup IXW medias have identical contents.
Purge buffer job. This job is not really part of IXW media writing, but it must be considered here
since no other instance deletes written documents from the disk buffer. The purge job scans the disk
buffer for documents and deletes those ones that are already written to optical media. It may,
however, decide to keep even such “old” documents depending on given purging rules; for example,
a rule may dictate that documents have to be retained for a certain number of days.
When a document has been found that is subject to deletion according to the purging rules, the
following steps are performed:
1. It is checked that the document is really present on the optical medium it is said to be, to
prevent deleting documents that are not really stored anywhere else (e. g. due to a medium
damage that has happened in the meantime).
2. Optionally (depending on purging rules), the document is copied to the cache.
3. The document is deleted from the disk buffer.
4. The storage database DS is informed about the deletion.

Free space on a IXW volume
IXW medias are written incrementally

A IXW partition is considered full even before the physical limit is
reached
2% of space is left empty by default (Archive Server ≤ 9.5 : 10%)
Remaining space is reserved for later use, i. e. for changes to notes/
annotations of documents resident on the same volume
Helps to keep all components of a document together on a single volume
Avoids collecting a retrieved document from multiple volumes
Default filling rate for original documents 2%
Physical storage media capacity

The percentage of space to be left empty is set globally during Archive Server installation.
2% is just a default suggestion of the installation routine since Archive Server ≥ 9.6.
In Archive Server ≤ 9.5, this value was 10%.
If this global setting is unsuitable for your purpose, it can be altered at any time:
ELS Administration Client (MMC) Runtime & Core Services Configuration:
Archive Server
└ AS.ADMS.DEFAULTS_POOLS.ADMS_WM_PART_PERCENT_FREE
Once altered, the change becomes effective after the next Archive Server restart. However, the
change affects only medias that are initialized henceforth. The space reservation for medias
already in use can be altered using the dsClient utility; see ESC document for details:
https://esc.ixos.com/0914004631-652
4-6 710-97
Writing documents to ISO media to DVD
(or WORM) (one Jukebox)
Archive Server
Storage database DS
E
Storage Manager
STORM
Document Service
ISO
tree ”Original”
B C
Write job
ISO
ISO
image
image
D
A Burn buffer
“Backup”
(optional)
Disk buffer Cache
Purge buffer job

The chart above illustrates the steps involved in writing documents from the disk buffer to ISO media to
DVD or WORM. This is organized as a periodic job:
ISO write job ; whenever the job is invoked (usually once a night), it performs the following steps:
(A) It checks the disk buffer for the amount of collected data. If it is too little to fill a medium, nothing
happens; the job finishes, waiting for its next invocation. Otherwise it continues with the next step.
(B) As a preparation for ISO media burning, the ISO image is created in the burn buffer. This “image”
is a single large file containing the complete file system layout for the target media; its contents is
the complete set of documents selected for burning.
To optimize read performance for the target media, the document files are sorted by their size
(large files first) before the ISO image is assembled; for this, the ISO tree structure is created in
the burn buffer.
(C) A medium is inserted into the jukebox’s writer drive and the ISO image is written to it.
Immediately afterwards, the medium is checked for writing errors (“verified”) by reading it
completely and comparing it with the ISO image in the burn buffer. Should writing faults be
detected, the medium is marked as “bad” and a further attempt to burn the ISO image on another
medium is made. (After the third unsuccessful attempt, the job assumes that the writer drive is
damaged, stops operation, and terminates with an error status.)
(D) If thus configured, a second medium is burned from the same ISO image and verified. Original
and backup are completely identical; no distinction is possible and necessary.
(E) The storage database DS is updated to reflect the new status and location of the processed
documents.
Purge buffer job. This job is not really part of ISO media writing, but it must be considered here since no
other instance deletes written documents from the disk buffer. The purge job scans the disk buffer for
documents and deletes those ones that are already written to optical media. It may, however, decide to
keep even such “old” documents depending on given purging rules; for example, a rule may dictate that
documents have to be retained for a certain number of days.
When a document has been found that is subject to deletion according to the purging rules, the following
steps are performed:
1. It is checked that the document is really present on the optical medium it is said to be, to prevent
deleting documents that are not really stored anywhere else (e. g. due to a medium damage that
has happened in the meantime).

Writing documents to ISO media to DVD
(or WORM) (two Jukeboxes)
Archive Server
Storage database DS
Storage Manager
D STORM
”Original” ”Backup”
Document Service
C
ISO
tree
Write job B Backup job

ISO
ISO
image
image
A Burn buffer
(optional)
Disk buffer Cache
Purge buffer job

The chart above illustrates the steps involved in writing documents from the disk buffer to ISO media to
DVD or WORM in case of using two jukeboxes.
ISO write job ; whenever the job is invoked (usually once a night), it performs the following steps:
(A) It checks the disk buffer for the amount of collected data. If it is too little to fill a medium, nothing
happens; the job finishes, waiting for its next invocation. Otherwise it continues with the next step.
(B) As a preparation for ISO media burning, the ISO image is created in the burn buffer. This “image” is a
single large file containing the complete file system layout for the target media; its contents is the
complete set of documents selected for burning.
To optimize read performance for the target media, the document files are sorted by their size (large
files first) before the ISO image is assembled; for this, the ISO tree structure is created in the burn
buffer.
(C) A medium is inserted into the jukebox’s writer drive and the ISO image is written to it.
Immediately afterwards, the medium is checked for writing errors (“verified”) by reading it completely
and comparing it with the ISO image in the burn buffer. Should writing faults be detected, the medium
is marked as “bad” and a further attempt to burn the ISO image on another medium is made. (After
the third unsuccessful attempt, the job assumes that the writer drive is damaged, stops operation, and
terminates with an error status.)
(D) The storage database DS is updated to reflect the new status and location of the processed
documents.
Backup job. The ISO media write job in this case not copies documents to the ISO media backup itself;
this task is left to the backup job that is normally executed once a night. After this, original and backup
ISO medias have identical contents.
Purge buffer job. This job is not really part of ISO media writing, but it must be considered here since no
documents and deletes those ones that are already written to optical media. It may, however, decide to
keep even such “old” documents depending on given purging rules; for example, a rule may dictate that
documents have to be retained for a certain number of days.
When a document has been found that is subject to deletion according to the purging rules, the following
steps are performed:
1. It is checked that the document is really present on the optical medium it is said to be, to prevent
deleting documents that are not really stored anywhere else (e. g. due to a medium damage that has
happened in the meantime).
4-8 710-97
Writing documents to ISO media to hard-disk
based Storage System (HD-WO)
Archive Server
Storage database DS
Storage Manager
D STORM
”Original” ”Backup”
Document Service
ISO
tree C
Write job B
ISO
ISO Backup job
image
image
A Burn buffer
(optional)
Disk buffer Cache
Purge buffer job

The chart above illustrates the steps involved in writing documents from the disk buffer to ISO
media on i.e. a hard-disk based storage system. This is organized as a periodic job; whenever the
job is invoked (usually once a night), it performs the following steps:
(A) It checks the disk buffer for the amount of collected data. If it is too little to fill a medium,
nothing happens; the job finishes, waiting for its next invocation. Otherwise it continues with
the next step.
(B) As a preparation for ISO media burning, the ISO image is created in the burn buffer. This
“image” is a single large file containing the complete file system layout for the target media;
its contents is the complete set of documents selected for burning.
To optimize read performance for the target media, the document files are sorted by their
size (large files first) before the ISO image is assembled; for this, the ISO tree structure is
created in the burn buffer.
(C) The ISO image is transferred to the storage system (conventions may vary depending on
storage system).
Immediately afterwards, the medium is checked for writing errors (“verified”) by reading it
completely and comparing it with the ISO image in the burn buffer. Should writing faults be
detected, the medium is marked as “bad” and a further attempt to burn the ISO image on
another medium is made. (After the third unsuccessful attempt, the job stops operation, and
terminates with an error status.)
Theoretically a second medium — i. e. the backup — can be written from the same ISO image
and verified. However, using backup usually won't apply to storage systems using HD-WO
method. Storage systems normally have their own backup mechanisms.
(D) Depending on the configuration, either (or none) of these actions is taken:
– The copied documents are deleted from the disk buffer.
– The copied documents are moved from the disk buffer to the cache (so that they
remain to be accessible fast)
Generally, storage systems have better access times than DVD or WORM jukeboxes.
Therefore, usually caching the disk buffer in a cache partition on the Archive Server
is less critical.
(E) The storage database DS is updated to reflect the new status and location of the processed
documents.

Writing documents to FS pool or VI pool
(hard disk)
Archive Server
Storage database DS
DocumentService
Write job
Disk buffer FS pool

Purge buffer job

The chart above illustrates the steps involved in writing documents from the disk buffer to an FS pool.
Both HDSK and FS pool write to hard disk as final destination. As opposed to HDSK pool, however, the
FS pool utilizes a disk buffer and has its own write job. This provides certain advantages, esp. when FS
pool is used in combination with certain storage systems like i.e. NetApp filers.
FS pool is available starting Archive Server ≥ 9.6 and replaces the HDSK pool. HDSK pools can usually
be migrated to FS pools fairly easily and it is recommended that HDSK pools are only used for test
purposes in the future.
The periodic jobs involved in writing to FS pools are the write job and the purge job. They are invoked by
the job schedule independently from each other, but the corresponding actions on a specific document
are always carried out in the order explained here.
FS write job. The write job copies document files from the disk buffer to the target FS pool. The
storage database DS is informed that the file is now resident on disk location designated to the FS
pool. The write job is usually scheduled to run rather often, e. g. every 30 minutes.
Purge buffer job. This job is not really part of the writing, but it must be considered here since no
documents and deletes those ones that are already written to final location. It may, however, decide
to keep even such “old” documents depending on given purging rules; for example, a rule may dictate
that documents have to be retained for a certain number of days.
When a document has been found that is subject to deletion according to the purging rules, the
following steps are performed:
1. It is checked that the document is really present on the optical medium it is said to be, to
prevent deleting documents that are not really stored anywhere else (e. g. due to a medium
damage that has happened in the meantime).
4-10 710-97
Providing a document for read access
Archive Server Searching

Storage data- Storage Manager order
base DS STORM
WORM
file system
Document Service
IXW pool
1 3
Retrieval
Disk buffer 2
ISO pool Cache
FS pool
HDSK pool 1
VI pool

The chart above illustrates how the Archive Server organizes to provide a document for retrieval by
a client. Since a document may be resident in one (or more than one at the same time) of
several locations, a reasonable, well-defined order of precedence is obeyed for accessing the
document:
1. First the storage database is queried whether the document is available either in a disk
buffer or in a hard disk pool. In either case, it is taken from there and transmitted to the
client.
2. If the document is not present in either a disk buffer or a hard disk pool (HDSK or FS), it
is checked whether the document is present in the cache. If so, it is taken from there and
transmitted to the client.
3. Only if the document cannot be taken from any hard disk location (cases 1 and 2) it is read
from an optical medium; this is the least attractive situation because reading from a
jukebox is much slower than from hard disk.
Before the document is actually transmitted to the client, it is first copied to the cache so
that subsequent read requests can be fulfilled from there. As a matter of optimization for
very large documents (like print lists), a document is cached in fragments of 64 kB size; only
those parts of the document are read, cached, and transmitted that are actually requested
by the client. As the user browses through the document in the Archive Windows Viewer,
the client automatically requests the desired parts from the server, step by step.
If the client application requesting the document is not able to load the document fragment-
wise, i. e. it insists on receiving the complete document immediately, then the cache will
receive the whole document as well.
When the cache becomed full, it flushes old documents as needed to make room for newly
requested ones (FIFO or LRU mechanism); unlike for the disk buffer, there is no periodic
job needed for cache reorganization.

4-12 710-97
5 Document Structure on Storage
Media
How the Archive Server arranges stored
documents
Slide 1
Document Structure on Storage Media 5-1

Chapter overview
Document structure
Documents and components
Directories and files
Tracing documents with dsClient
Cache structure
Document Structure on Storage Media • Slide 2

5-2 710-97
Inner structure of documents
Documents are identified by Document

components attrib.atr
unique document IDs (also known
as document string) info.txt
OLE
annotation
data
Documents are composed of Annotations
components: E-mail
Notes
Document body, e. g.
Page n
– collection of scanned
images Page 1
– single multi-page image Notes
– single PDF, DOC, … file Scan Page index
“Helper” components document
(e. g. indexes into the document) Search index
User comments
List body
– Notes
– Annotations Documents
– OLE annotations (type examples) SAP
print list

Every document stored on an Document Structure on Storage Media is composed of components. These can
be classified into these categories:
• The “document body” itself, e. g. a single PDF file.
Regarding scanned documents, the body may in turn consist of multiple components, i.e. the
sequence of scanned document pages each of which is stored as a separate image file. (Binding all
scanned pages together into a single multi-page file is also possible; this is done by the scanning
application, not by the Document Structure on Storage Media.)
• Additional “helper” components of the document. Examples:
– Collections of application-related attribute sets (for retrieval database recovery)
– Page index for SAP print list (for efficient page-wise viewing)
– Attribute search index for SAP print list (for efficient table search)
These components are not normally visible as part of the document; they are used by the system
components behind the scenes for certain purposes.
• Comments that users create and store along with documents. These include:
– Notes
– Annotations, which in turn are subdivided into:
∗ “Normal” annotations, i. e. vector-graphic objects. All such annotations of a document
are collected in a single annotation component.
∗ OLE annotations, i. e. OLE objects embedded into the document. Since these
normally contain quite much data, the Document Structure on Storage Media stores
every OLE annotation as a separate component.
Notes and annotations are alterable (notes: extensible only) by the users. To manage this on write-
once media, document components have a version attribute. Every time a user adds a note, all notes
together are stored once again as the notes component with the next available version number; every
new version supersedes all older versions. If physically possible, older versions are even deleted as a
new one is stored in order to regain storage space. The same applies to annotations (except for OLE
annotations).

Directory structure on storage media
“Distribution” layers
Avoid storing too many items in a
single directory
(limitation or performance loss on
operating system level)
“Random” structure
(no implied meaning)
Same structure on all storage media

Disk buffer
Hard disk pool
Optical disks
Exceptions:
Cache (but similar)
3 “distribution” 4rd layer: Document Pipeline
layers directory = document
Names are 1-byte Names are 4-bytes
Path to document is retained
hex numbers hex numbers throughout the processing flow
Relative to medium root directory
5-4 710-97
Files of documents
Files = document components
Number and types depend on Example: scanned document (2 pages)
document type and scenario Directory
Directory 88/96/86/00000963:
88/96/86/00000963:
Prefix rd.: Size
Size Name
Name
file marked as read-only 174
174 .job.W1_WP
.job.W1_WP
Suffix ;n: component version 521
521 ATTRIB.ATR
ATTRIB.ATR
number 121880 rd.1.PG;1
121880 rd.1.PG;1
– For revisable components like 54576
54576 rd.2.PG;1
rd.2.PG;1
notes, annotations 381 3F21295C.022
381 3F21295C.022
136
136 NOTE.;2
NOTE.;2
Additional “administrative” files:
ATTRIB.ATR
– Accompanies every document Example: SAP print list
– Contains all technical document Directory
attributes (e. g. document ID) Directory 22/82/89/000014B4:
22/82/89/000014B4:
Size
Size Name
Name
– Needed for database imports
226
226 .job.A1_ISO
.job.A1_ISO
.job.<ARCHIVE>_<POOL> 469
469 ATTRIB.ATR
ATTRIB.ATR
– Only in disk buffer 6832486 DATA.;1
6832486 DATA.;1
– Indicates that document (or part 00 DESCR.;1
DESCR.;1
of it) is not yet written to target 3474
3474 PAGELIST.;1
PAGELIST.;1
media
– Needed for disk buffer recovery
Every document component is stored as a file in the document’s directory (discussed on the
previous page).
Before copying documents to final media, the write jobs marks components as read-only with the
prefix .rd. This ensures that the files are not changed anymore i. e. on the diskbuffer.

System attributes in the ATTRIB.ATR
.A :.A=archive-id Archive ID, name of the archive

.D :.D=creationdate Creation date of the document
.L :.L=doc-id Doc ID, name of the document
.R :.R=retention Retention of document
.TS :.TS=timestamp Date and time at which ATTRIB.ATR was written
.Y :.Y=docType Document type within the DS
.C compsname :.C= number Status of compression and encryption
.CRC32 compsname :.CRC32=number Ckecksum of a componet
.CL-SIG compsname :.CL-SIG=signature Cryptographic checksum and signature with the date of
the component
.D compsname :.D=creationdate Creation date of the component
.F Compsname:.F=flags Flags for each component
.L Compsname:.L=compname Compsname-compname assignment
.P Compsname:.P=protvers Protocol version of the component
.T Compname:.T=type (Mime-)Type of the component
.SIG Compsname:.SIG=signature Cryptographic checksum and signature with the date of
the component

.C addition of following values:

• 0x01: already compressed 0x0001
• 0x02: don’t compressed 0x0010 0x0010
• 0x04: already encrypted 0x0100
• 0x08: don’t encrypt 0x1000 0x1000
• typical value .C=10 means: sum =0x1010
see also https://knowledge.opentext.com/knowledge/llisapi.dll/open/15529600/
5-6 710-97
Tracing documents with dsClient (1)
PROMPT>
PROMPT> dsClient
dsClient localhost
localhost dsadmin
dsadmin [password]
[password] Identify
Identify by
by document
document ID
ID
->
-> dinfo
dinfo aaajclfhitjt32mqp3fmus5qglvzk
aaajclfhitjt32mqp3fmus5qglvzk
docIdNo=2403
docIdNo=2403 path=88\96\86\00000963
path=88\96\86\00000963 noOfComps=4
noOfComps=4
creationDate=Mon
creationDate=Mon Jul
Jul 2828 11:56:09
11:56:09 2003
2003
modificationDate=Mon
modificationDate=Mon Jul Jul 28
28 12:42:05
12:42:05 2003
2003 Relative
Relative document
document pathpath
status=0x10( DB ), archive=W1
status=0x10( DB ), archive=W1
rights=3f ( R W C N D A ) Identical
Identical on
on all
all media
media
rights=3f ( R W C N D A )
component
component type
type volume
volume version
version
1.pg
1.pg image/tiff
image/tiff Diskbuf1
Diskbuf1 11
1.pg
1.pg image/tiff
image/tiff W1_015B
W1_015B 11
2.pg image/tiff Diskbuf1 This
This component
component is is stored
stored
2.pg image/tiff Diskbuf1 11 twice:
twice: in
in disk
disk buffer
buffer and
and
2.pg
2.pg image/tiff
image/tiff W1_015B
W1_015B 11 on WORM
anno.ixos on WORM
anno.ixos application/x-ascii_anno
application/x-ascii_anno Diskbuf1
Diskbuf1 22
note
note application/x-note
application/x-note Diskbuf1
Diskbuf1 22
->
-> volInfo
volInfo Diskbuf1
Diskbuf1
poolNames Find
Find entry
entry point
point of
of
poolNames : Buffer1
: Buffer1 current
current storage
storage volume
volume
Name: Diskbuf1 Id: 1 BaseDir:
Name: Diskbuf1 Id: 1 BaseDir: D:\D:\
Cap:
Cap: 15967645
15967645 percFree:
percFree: 10
10 Type:
Type: HDSK
HDSK
blksFree:
blksFree: 3314350 trueFree: 3314350
3314350 trueFree: 3314350 trueUsed:
trueUsed: 12304817
12304817
status:
status: 16
16 (( VOL_MODIFIED
VOL_MODIFIED ))

The Document Structure on Storage Media command line tool dsClient is useful for retrieving
complete information about a certain stored document. Starting from the document ID — that you
must know in advance — you can use the dinfo command to inform yourself about:
• The logical archive the document is stored in
• Time of archiving and of last modification (i. e. entry of notes or annotations)
• Components belonging to the document
• Current storage location, composed of
– the path (valid for the whole document, on all storage media)
– name of the current storage media (for each component separately)
To really know the storage location(s) of a document component in the disk buffer, you have do go
one step further: The logical media names given in dinfo’s component list have to be mapped to
true storage locations in the Document Structure on Storage Media’s filesystem. This is done with
the volInfo command as illustrated above. The BaseDir attribute of the named volume together
with the document path form the complete storage path.
Calling dsClient, you may enter the user’s password directly on the command line, as illustrated
above; however, this is somewhat insecure because the password is then visible both on the
command console display and in the computer’s process list. It is also possible (and more secure)
to omit the password on the command line, in which case dsClient will prompt you for the
password upon startup; the typed password is not displayed on the screen then.
To exit from dsClient, use the end command.

Tracing documents with dsClient (2):
document component details
original
original component
component name
name
->
-> cinfo
cinfo aaajclfhitjt32mqp3fmus5qglvzk
aaajclfhitjt32mqp3fmus5qglvzk anno.ixos
anno.ixos
Component
Component anno.ixos
anno.ixos
versNo=1
versNo=1 type=application/x-ascii_anno
type=application/x-ascii_anno size=182
size=182 protVers=0045
protVers=0045 flags=0
flags=0
creationDate=Thu Jul 31 11:26:24 2003
creationDate=Thu Jul 31 11:26:24 2003
status=0x10(
status=0x10( DBDB ))
pathName=H:\\.\88\96\86\00000967\3F28E0C0.002
pathName=H:\\.\88\96\86\00000967\3F28E0C0.002
cacheName=F:\.\88\96\86\00000967\3F28E0C0.002
cacheName=F:\.\88\96\86\00000967\3F28E0C0.002
volName=Diskbuffer_Part1
ISO
ISO compatible
compatible component
component name
name
view of connection between the component
names in the ATTRIB.ATR:
…
3F28E0C0.002:.L=anno.ixos;1
…

Normally, the logical name of a document component and the name of the corresponding file are
identical. However, this does not hold for component names longer than 8+3 characters: To be
conformant with the older ISO 9660 filesystem standard for CDs, the DocumentService uses
artificial 8.3 file names for such components.
In such a situation, it is not always obvious which document component corresponds to which
stored file. To retrieve the mapping, use dsClient’s cinfo command as illustrated above.
5-8 710-97
Document structure in the cache
Same
Same 44 directory
directory levels
levels
as
as on
on storage
storage media
media
Directories
Directories represent
represent
document
document components
components
Files
Files are
are cached
cached inin
chunks
chunks ofof 64
64 kB,
kB, as
as
requested
requested byby client
client

The directory and file structure in the Document Structure on Storage Media’s cache is slightly
different to the one used on the storage media:
• The three-layer directory structure down to the document directories is the same;
documents retain their specific path even in the cache.
• Document components — normally stored as files — are represented as directories in the
cache. The name of such a component directory equals the name of the component file on
the storage media.
• Within a component directory, the component contents is stored as a set of enumerated
files: Each of those files contains a chunk of the component file with size 64 kB (except for
the last one which may be smaller). This structure enables chuck-wise caching of large
documents — only those fragments of a document are cached which are actually requested
by a client. This speeds up caching and prevents huge documents from flushing many
smaller documents from the cache at once.
However, a document is always cached entirely (but still as a set of chuck files) in these
situations:
– When it is cached as part of the media write or buffer purge action
– When it is requested by a leading application that does not support chunk-wise
document retrieval

Exercise: Examine a document on storage media
Retrieve document ID of sample

document
Find its storage location using
dsClient
Examine the document files found in

the disk buffer
Add a note to the document and
examine the result
in dsClient
in disk buffer partition

5-10 710-97
6 IXW File system - WORM File
system
How the Document Structure on Storage
Media
manages data on IXW media
Slide 1
IXW File system - WORM File system 6-1

Chapter overview
IXW file system structure
IXW file system database
IXW finalization
IXW File system - WORM File system • Slide 2

6-2 710-97
IXW: The Open Text file system for UDO and
WORM medias
Open Text uses proprietary file system for UDO and WORM medias
No industry standard available
Requirements:
Incremental writing
Space efficiency
Robustness against “bad blocks”
Recoverability from write errors
Fast read access
The Open Text solution:

File structure information in separate WORM file system database


How IXW medias are written
WORM inode 3
file system inode 2
database inode 1
A IXW volume
VCB VCB FCB FCB FCB Data file D.f. Data file
1 2 1 2 3 3 2 1
Volume File/directory
Free space Free Application data (= files)
header structure
Fixed Fixed Variable

division division division

From the point of view of the file system structure, a IXW media can be regarded as a sequence of blocks
with fixed size (normally 1, 2, or 4 kB). The illustration above shows how the Archive Server manages the
data written to a IXW media. The storage space of every IXW media is subdivided into these areas:
• Free space is left at the beginning of the IXW media. The exact amount differs, depending on the
used STORM version; it is never more than 1 MB. (For more details, see
https://knowledge.opentext.com/knowledge/llisapi.dll/open/15538189)
Attention! Is available from version 4.1
• The volume header (also called VCB area) contains information about the volume itself, such as the
volume label and the time of initialization. The information is packed into a volume control block
(VCB). Since the status of the WORM may change later (e. g. due to a promotion of a backup to an
original), additional VCBs can be appended later on, each one superseding the previous one. The
space reserved for VCBs is 16kB.
• The structure or FCB area contains the file control blocks (FCBs). Every FCB contains status
information about a written data file, including a pointer to the location of the file on the IXW media
itself.
• The last area on the IXW media contains the application data, i. e. the actual documents files.
• Between the FCB area and the data area, a certain amount of free space is left for later storing the
finalization data (see later in this chapter).
Whenever a data file is to be written to a IXW media, these items are actually stored:
• The FCB with file attributes and the pointer to the file storage location (block number).
• The file itself, appended to already written data at the end of the IXW media.
• An inode is created in the WORM filesystem database. This inode basically mirrors the file attributes
already stored in the corresponding FCB.
While it does not add information to the FCBs, the WORM filesystem database is essential for fast access
to IXW media data. The FCBs are always stored in chronological order of writing and therefore cannot be
searched efficiently.
6-4 710-97
WORM file system database
File path, e. g.
Mirror WORM file system structure on FM001/15/97/00012D/DATA.;1
hard disks for fast access
Also called the inode cache
WORM
WORMFS
FSDB
DB
Maps file paths to file attributes and
location
File information:
Stored as files (not in DBMS) Creation date
Location (block offset)
Fixed size, determined during Archive on WORM
Server installation Size
…
Size and filling level displayed in
Archive Server Monitor
or with command line tool: Indexes into inode data
cdadm read fs%worm%cache
Size and location of files

configured in STORM inodes
inodes inodes
inodes inodes
inodes
hashdir hashname hashfile
config file server.cfg
inodes
inodes
inodes
The structure data itself

The role and significance of the WORM files system database (= inode cache) are the same as of
the well-known FAT (file allocation table) of Windows file systems: It takes a file path as input and
maps it onto the file’s physical storage location (necessary to read the file) as well as other status
information.
The WORM files system database is no database from the software point of view; no DBMS is
used to store the information. Instead, the data is stored in a variable number of different files (as
illustrated above) that STORM uses as a database in a logical sense.
STORM’s central configuration file, <archive_path>/config/storm/server.cfg,
determines the number, sizes, and location of the data files. The information is coded in the
ixworm section that looks like this:
ixworm {
numInodes { 100000 } (max. total number of inodes)
ixwhashdir {
files { file1 file2 } (list of configured files of this type)
file1 {
path { W:/hashdir1 } (path of file1)
size { 25 } (max. size of file1 in MB)
...
}
...
}
ixwhashfile {...} (same structure as ixwhashdir)
ixwhashname {...}
ixwinodes {...}
}
The total number of inodes would be defined in the time of the configuration of the archive server.
If it later necessary to increase this value, please contact the Archive Server Support.

IXW media finalization (1)
WORM filesystem database

(inode cache)
inode 3
inode 2 Finalization =
inode 1 moving structure information
onto the IXW media
Reference to entry address of ISO structure
ISO
PVD VCB VCB FCB FCB FCB Data file D.f. Data file
structure
File/directory
Application data (= files)
structure

When a IXW media has been filled up with document files, it may become finalized. The chart
above illustrates how this is done:
1. The complete inode data describing the IXW media contents is copied from the WORM
filesystem database to the IXW media itself. The resulting ISO structure is a complete,
searchable structure description of the IXW media contents. It is written into the remaining
free space between the FCB and data areas; this space is kept free explicitly for exactly that
purpose.
2. The inodes of the IXW media volume are deleted from the WORM filesystem database.
3. A primary volume descriptor (PVD) is written at the beginning of the WORM volume,
pointing to the block where the ISO structure can be entered for searching.
The ISO structure and the PVD turn the IXW media into a read-only ISO medium which can be
accessed efficiently without the WORM FS database.
See next page for a discussion of further consequences of finalization.
6-6 710-97
IXW media finalization (2): Properties
Finalized IXW media accessible without WORM FS database

Objective: keep WORM filesystem database small
IXW media becomes read-only ISO 9660 filesystem
Backup IXW media is finalized automatically
As soon as finalized original is backed up
After this: no more distinction between original and backup
Finalization can be done during normal server operation
Does not block other access to the required resources (media and drive)
Finalization may fail in certain cases
For example, if bad blocks in the reserved space prevent writing
Old media initialized with ixwd can generally not be finalized
(migrate to new IXW medias first)
In these cases:
WORM filesystem database must keep structure data “forever”
Nevertheless, IXW partition remains read-only

For customers with Unix-based Archive Server installations upgraded from an original release ≤
3.5, there is an important restriction: All WORM partitions that were initialized by IXOS’s old
jukebox service ixwd cannot be finalized at all. In order to benefit from finalization, those WORMs
must first be copied to new ones which then can be finalized afterwards.
This is positional in the missing PVD (primary volume descriptor) field on the WORMs (see also
the picture on slide 6 on this chapter).

IXW medias and the ISO9660 filesystem standard
Finalization converts a IXW media to an ISO9660 filesystem

ISO9660 limitation: no more than 65’000 directories
If a finalized IXW media contains more than 65’000 directories:
WORM becomes nearly, but not fully ISO9660 compliant
No problem for file access by Archive Server
Archive Server obeys this ISO limitation when writing to IXW medias
Leads to 100% ISO9660-compliant WORM media
WORMs may not become full (esp. when storing mainly very small files)
Default setting
To have the Archive Server fill up IXW medias even with small files,
configure it to ignore the limitation
– See KC

The fact that — by default — an Archive Server stops adding directories (= documents) to a IXW
media partition when the 65’000 directories limit for ISO9660 media is reached, may lead to
significant space waste on modern, large IXW medias — especially where mainly small documents
are stored. You should therefore consider switching this limit off; there is no negative impact
concerning the Archive Server’s own use of media exceeding this limit.
The option for obeying the ISO directory number limit can be maintained in the STORM
configuration:
<archive_path>/config/storm/server.cfg
Find more information in the related KC article:

https://knowledge.opentext.com/knowledge/llisapi.dll/open/15538931
6-8 710-97
7 Configuring Logical Archives
Separating documents physically
Slide 1
Configuring Logical Archives 7-1

Chapter guide
Logical archive fundamentals
Definition
Pros and cons for multiple logical archives
Technical background
Pools
Devices
Configuration
Archives
Pools
Document processing options
Configuring Logical Archives • Slide 2

7-2 710-97
Definition: logical archives
A subdivision of an Archive Server’s storage resources

Every storage medium is assigned uniquely to one logical archive
Every stored document resides in one specific logical archive
Visible to the leading application
Leading application controls distribution of documents to logical archives
Used to handle classes of documents differently, e. g.
different retention periods
different requirements for fast retrievability
Characterized by a set of technical properties
Media type
(DVD, WORM, UDO, HD, HD-WO)
Archive
ArchiveServer
Server
Writing schedule
Log.
Log. arch.
arch. A
A Log.
Log. arch.
arch. B
B Log.
Log. arch.
arch. C
C
Caching behavior
Security settings


Why use more than one logical archive?
To differentiate document retention periods/compliance

requirements
Business reasons
To differentiate access authorizations

Controlled by leading application
To reflect organizational structure

Independent companies
Company codes
To keep documents of different leading applications separate

Technical reasons
To differentiate storage and caching methods

Affecting fast accessibility
Affecting fault-tolerant availability
To use different media types (hard disk, DVD, HD-WO, UDO or WORM)
To distinguish test and production context

For maintaining background forms using i.e. Forms Management with SAP Document Archiving, a
dedicated logical hard disk archive is strongly recommended.
Furthermore, it is recommended to use separate logical archives for document archiving and for
data archiving purposes.
7-4 710-97
Restrictions for the number
of logical archives
Archive IDs must be unique

Each logical archive ID must occur on only one Archive Server in your Open
Text storage environment
Leading application may impose similar restriction
– Example SAP: One logical archive to be used by a single SAP only
On one Archive Server : Avoid having too many

For ISO (= write-at-once) storage media: Hard disk space for disk buffer must
be provided proportional to the number of logical archives
The incoming archive traffic must be sufficient to fill a ISO media
(DVD, WORM or HD-WO) in time
The needed number of optical media must fit into your jukebox
(esp. UDO and WORM)


Chapter guide

Definition
Pools
Devices
Configuration
Archives
Pools

7-6 710-97
Inner structure of a logical archive
Leading
Leading Archive
ArchiveServer
Server
application
application
Logical archive
A1
A1 A1
A1
Security Media
Mediapool
pool
Securitysettings
settings
Document
Documentproces-
proces- Media
Mediatype
type
sing
singoptions
options Writing
Writingoptions
options
Cache
Cacheserver
server Write
assignments Writejob
job
assignments Name
Name
Retention
Retentionsetting
setting Schedule
Schedule
Disk
Diskbuffer
buffer Medium
Medium11
assignment
assignment Medium
Medium22
Application
Applicationtype
type
Medium
Medium33
Media pool
Media type
…

Each logical archive must be defined on both the leading application and the Archive Server for
with the same name (’A1’ is just an example in the chart above); this is the foundation for the
storage dynamics controlled by the leading application and performed by the Archive Server.
On the Archive Server, a logical archive normally has a single media pool; in practice, it is
therefore not necessary to strictly distinguish between the archive and its pool. However, certain
exceptions exist where a logical archive may have more than one pool:
• If certain components of documents — specifically comments added by users, i. e. notes
and annotations — shall be stored on different media than the original documents. The
pools must then have different application type properties.
In practice, the most useful combination is:
– Storing original documents and notes on optical media
– Storing annotations on hard disks
This setup saves space on optical media. Since annotations are alterable at any time, it is
normally not necessary to store them on read-only media.
• If a media migration shall be performed for that logical archive. One pool must then have
application type “Migration”.
• Using the pooling feature in former versions of Email Archiving for MS Exchange/ Lotus
Notes.

Pool
A named group of storage partitions of the same media type

Following pool types possible:
ISO (write-at-once) (formerly: CD pool)
IXW (write-incremental) (formerly: WORM pool)
FS (single file) (buffered hard-disk)
VI (single file) (Single File Vendor Interface, EMC Centera)
HDSK (write-through) (recommended only for test purposes)
ISO, IXW, FS and VI pools require a hard disk buffer

Each ISO , IXW, FS and VI pool has its own media write job, including
job schedule “when and how often to run?”
job settings (caching, backup, …) “what to do exactly during
“ media writing?”

Pool type VI – Single File Vendor Interface

VI supports single files (instead of ISO images) for archiving on a storage system. Currently, only
EMC Centera is supported.
Pool type FS – Single File Filesystem

Both HDSK and FS pools use a hard disk device. Unlike HDSK pools however, FS pools use the
diskbuffer and have a designated write job. With Archive Server ≥ 9.6, FS pools should be used
instead of HDSK pools. HDSK pools should only be used for test purposes.
FS pools can be used along with local hard disks or with suitable storage systems (i. e. HDS,
NetApp, …).
7-8 710-97
Storage Systems supporting FS pools
Libraries to hide
Archive Server storage specific
Document Service settings of WORM
feature and
Disk Buffer retention periods.
STORM (cfs devices)
Library name
corresponds to
volume description
file.
libhdsk libsamfs libnetapp <libothers> ...
DS and STORM
use same libraries
Enabled storage platforms:
SAM FS
Hard Disk NetApp <others > ...
NAS5310
Provide volume description file:

archive.vdf
Writing on hard-disk using libhdsk supports compliance features (unlike HDSK pools).

Devices
Physical “containers” for storage media

Supported device types
WORM/UDO jukeboxes (IXW)
DVD/WORM jukeboxes (ISO)
"Virtual jukeboxes" (HD-WO)
Hard disk drives (FS, HDSK)
Storage systems use

for writing ISO images: "Virtual jukeboxes" (HD-WO)
for writing single files: hard disk files (FS or VI)
Hard disk devices are used for
Disk buffers
Hard disk pools
Devices are handled via the Archive Server Administration

Depending on the storage system, documents are either written as single files or ISO images.
ISO images are written using "virtual jukeboxes" in "hard-disk write-once mode" (HD-WO). These
are handled similar to ISO pools.
Single files are written usually using hard-disk drives in write-through method directly from DS.
7-10 710-97
Chapter guide

Definition
Pools
Devices
Configuration
Archives
Pools


Create an Original Archive (Logical Archive)

Invoke the New Archive dialog as illustrated above and supply the logical archive’s name and —
optionally — a description.
Reminder: For a logical archive for SAP, traditionally two-letter, uppercase, alpha-numerical
names are used (historic restriction for SAP ArchiveLink Interface).
7-12 710-97
Create ISO (write-at-once) pool (1):
Pool name and type

Having created a logical archive (as shown on the previous page), the next configuration step is
creating a media pool. For this,click on New Pool... in the Original Archive's Actions in the ELS
Administration (as illustrated above). You will then be guided through several dialogs where you
have to enter the following pool attributes:
The Pool name (which does not need to be unique among the logical archives) and pool
type (= type of media that the pool shall use: ISO, IXW, FS, VI or HDSK).

Storage tier, Buffering, Writing, Backup
2
Next
DVD Jukebox
Fill in these fields only for asynchronous backup

If backup shall be created in second jukebox & or at a later point of time
Step (illustrated above) queries details of how data shall be transferred from disk buffer to DVD
media. For a standard ISO pool configuration, specify the following items:
Storage tier: Do not select.
Used disk buffer: A disk buffer has to be chosen for collecting documents prior to writing them
to final media.
Write job: Writing data from disk buffer to media is a periodic job that needs to be scheduled.
This job will later be visible and maintainable in System → Jobs.
Original jukebox: Select the jukebox where media for this pool shall be written to.
Volume name pattern: Determines how newly created media will be labeled. “$(...)” are
placeholders for changeable values; $(SEQ) (= sequential number) must always be
present. You can check the effect of your pattern with the Test Pattern button.
Allowed media type: Choose here the type of media that you intend to use for this pool, i.e.
DVD-R.
Number of volumes: For each ISO volume, that many identical pieces are created. For test
data, choose ‘1’; for production ‘2’ (original plus backup) should be sufficient.
Minimum amount of data: If less than that amount of data is queued in this pool for writing, no
disk will be written; more archived data is waited for instead.
Backup: Do not select.
Backup jukebox: In cases where backup is used, select the jukebox where the backup disks
shall be burned.
Number of Backups: In cases where backup is used, this is normally ‘1’.
Number of Drives: In cases where backup is used, it tells the backup job — which copies
original disks to their backups — how many jukebox drives it is allowed to occupy
simultaneously. This may speed up the backup process, provided that enough drives are
available. Minimum is ‘1’.
7-14 710-97
Scheduling write job
Next 3

+ Writing data from disk buffer to media is a periodic job that needs to be scheduled here.
Specify the job period and frequency. The illustration shows a reasonable choice for a ISO
pool: once per night.

Use ISO pool with HD-WO
(hard disk write-once) media (1)
HD-WO pools also write ISO images

operation method for hard disk based storage
system (EMC Centera, HDS, NetApp, …)

7-16 710-97
Use ISO pool with HD-WO
(hard disk write-once) media (2)
Example for storage system writing ISO images in HD-WO mode

(i. e. EMC Centera, HDS, NetApp)
Further settings necessary
See installation guides
Advisable to involve Open Text Consulting for implementation
Next

Allowed media type

Choose the media type HD-WO and define the maximum size of an ISO image (in MB) as part of
the whole storage media separated by a colon!
Number of volumes
Enter 1.
Minimum Amount of Data
Enter a value less than the maximum size of an ISO image that you enter in the Allowed Media
Type field.
Backup
Do not enable backup. Usually, the storage system will take care of further backup.
Note:
Backup of documents stored on hard disk based storage systems (e. g. EMC Centera, HDS) can
be handled by the storage system itself and has to be configured appropriately.
In such a case you must not enable backup.

Create IXW (write-incremental) Pool
WORM Jukebox
Write
Writejob
jobschedule
schedule
WORM Jukebox Naming
Namingproposal:
proposal:
Write_WORM_D0
Write_WORM_D0
Typical
Typicalschedule:
schedule:
Hourly
Hourly
Creating and setting up an IXW pool is different from a ISO pool; this corresponds to the
differences in media writing techniques (ISO: one-time, synchonous backup; IXW: incremental,
asynchronous backup). These are the attribute differences:
The pool type must be “Write incremental (IXW)”.
IXW write configuration does not refer to a minimum amount of data to be written. Only the
following parameters are to be specified:
Auto Initialization is a recommended option. This way, new WORMs don't need to be initialized and
assigned manually. Auto Initialize also takes care of initializing the backup WORM.
Backup: If selected, IXW volumes of this pool will be backed up automatically; always
select for pools containing production data.
Since there is no need to wait for a certain amount of archived data to fill a volume completely,
IXW media writing can be scheduled much more often than ISO media writing, i.e. every
hour/half-hour.
Like an ISO pool, an IXW pool needs a disk buffer for collecting documents prior to writing them
to the media.
7-18 710-97
Create FS (single file) Pool
Write
Writejob
jobschedule
schedule
Naming
Namingproposal:
proposal:
Write_FS_F0
Write_FS_F0
Typical
Typicalschedule:
schedule:
Hourly
Hourly

Creating and setting up an FS (single file) pool is different from an ISO pool; this corresponds to
the differences in media writing techniques (ISO: one-time; FS: frequent writing). These are the
attribute differences:
– The pool type must be “Single File (FS)”.
– HD write configuration does not refer to a minimum amount of data to be written.
– Since there is no need to wait for a certain amount of archived data to fill a volume
completely, HD writing can be scheduled much more often than ISO media writing.
The shortest period that can be specified is every five minutes.
– Like an ISO pool, a Single File (FS) pool needs a disk buffer for collecting documents
prior to writing them to media.

Create HDSK (write-through) pool

Since the availability of FS (single file), HDSK (write-through) pool is only recommended for test
purposes. Whenever possible use FS pools instead.
To complete the picture of media pool setup, here is how to create and set up a hard disk pool:
– As a preparation step, you first have to provide a hard disk partition on operating system level.
On a Unix-based Archive Server, make sure the root directory of the file system is owned by
the user/group that the Archive Server is operated as and has permissions 770.
– The pool type must be “Write thru (HDSK)”.
– No job for writing to optical disks and no disk buffer are involved. A hard disk pool directly and
finally stores documents on hard disk volume(s); therefore, you have to assign the prepared
hard disk partition to the pool directly.
– Specify the following:
Partition name: A (preferably meaningful) logical name for this volume; must be unique
throughout all volume names (including IXW medias) of this Archive Server. The
Archive Server will henceforth maintain the volume by this name.
Mount path: The root directory of the partition’s file system. On Windows NT, this should
be a drive specification (including a backslash); on Unix platforms, it is the directory
where the partition is mounted; on Windows 2000 or greater, it can be either of both,
depending on how the partition is hooked into the file system.
If, on a Windows-based Archive Server, you want to use a network share instead of a
local hard disk drive, see KC article
https://knowledge.opentext.com/knowledge/llisapi.dll/open/15527080/ about
how to do that exactly.
If you choose to divide the total storage space of the pool into more than one partition, you have to attach all
but the first partition to the pool after the pool has been created.
7-20 710-97
Set document processing options (1)
Caching of documents upon

reading from storage system Document
STORM Service
Retrieval
Should always be activated — except if:
– Storing huge documents that are
expected to be retrieved only seldom
Cache
Compression to save space on storage media

Often recommended

All settings discussed on this and the following pages are to be made per logical archive, i. e. you
may configure the Archive Server to treat documents in separate logical archives differently.

Set document processing options (2)
BLOBs to optimize storage of small files

Recommended where mainly small files are
stored
Single instance for storing identical files only
once
Recommended for especially for email solutions
ArchiSig Timestamps to enable validating
document authenticity
Use only if explicitly demanded
Requires further configuration steps
(timestamp server setup)
Delayed Archiving to hold back documents

in Diskbuffer
When retention period cannot be set by leading
application during archiving
Leading application triggers writing to final
storage, for i.e. workflow scenarios

7-22 710-97
Set security options (for HTTP access)
Signature: Allow or deny unsigned document access

Protection requires leading application to “sign” access requests with SecKeys
To be specified separately for access types: read, create, update, delete
Commonly used settings:
– Read, create, update, delete ← full protection against unauthorized access
– Delete ← all access (except deletion) freely allowed
Enforce SSL usage for communication

Requires a customer-specific certificate on the Archive Server
Test certificate is preinstalled by IXOS
Control Document Deletion

Common setting is Allowed

Meaning of the Use SSL options:

Use (y): Clients must use SSL.
Don’t use (n): Archive Server forces clients not to use SSL.
May use (m): Archive Server accepts requests both using and not using SSL; every client
decides individually, dependent on client-side configuration settings
See the Archive Server Administration Guide for details about how to install a customer-provided
SSL certificate.
Document deletion options:

Allowed : Regular behavior.
Causes error : When a user or an application tries to delete a document, there will be an
error message as response.
Ignored : Attempts to delete a document will be ignored without an error message.

Exercise: Create logical archive with media pool on
Archive Server
Create logical archive

Create an ISO, IXW, FS and Harddisk
pool
Specify writing parameters
Schedule write job
Set processing options

Set security options
i. e. require signature for Delete

7-24 710-97
8 Disk Buffer Configuration
Setups for intermediate document storage
Slide 1
Disk Buffer Configuration 8-1

Chapter guide
Disk buffer fundamentals
Additional roles of the disk buffer

Backup
Caching
Configuration examples
Sizing
Creating, assigning to pools
Disk Buffer Configuration • Slide 2

8-2 710-97
Stores documents safely until they are written to final storage

Document Service
Doc. Pipeline STORM
Document
sources
Disk buffer FS pool

VI pool
May retain documents even after writing to optical disks

For faster access than from optical disk→ caching
For data loss protection → temporary backup
Documents have to be purged periodically
Must be equipped with one ore several hard disk partitions
Required by optical media pools, "virtual jukeboxes" &
buffered hard disk pools
ISO, IXW, HD-WO, FS, VI


Disk buffer purging
Buffer purging properties:

Removes “old” documents only, i. e.
those that have already been written to
optical media
Job should be run once a day
– Preferably during times of low system
activity
Selects documents for purging
according to given rules Buffer purging properties
May move documents to the cache
instead of simply deleting them

Each disk buffer possesses a periodic purge buffer job that, when invoked, searches the buffer for
“old documents” (i. e. documents that have already been written to optical disk) and removes them
according to certain criteria:
• If a percentage of free buffer space for newly archived documents (“Required avail. space”)
is specified, the job removes so many documents (oldest first) that the required space
amount is freed. If, however, the required space amount cannot be freed because the buffer
is populated with too many not-yet-written documents, the job frees as much space as
possible by removing old documents.
• If a retention period for old documents (“Clear archived documents older than …”) is
specified, documents older than that period are removed — even if the claimed percentage
of space is already free.
Moreover, you can choose to copy a document to the read cache immediately before removing it
from the disk buffer (“Cache before purging”). This way, the document’s fast availability is
continued by the cache after its removal from the disk buffer.
The buffer purge job causes considerable hard disk, CPU, and storage system on the Archive
Server:
1. It searches the disk buffer volumes for documents matching the purging selection criteria.
2. For each selected document, it checks in the storage database and on the optical target
medium that the document is really stored there (in order not to lose documents in case of
an inconsistency between database and media).
3. If everything is okay, it deletes the document’s files on the disk buffer volume.
For this reason, it should preferably be scheduled to run when there is not much other activity on
the Archive Server, e. g. during the night and not simultaneously with the local backup job (making
IXW media backups).
8-4 710-97
Chapter guide
Backup
Caching
Sizing


Disk buffer as temporary IXW media backup
Disk buffer must keep documents

STORM
until backed up
on backup IXW media Disk buffer
Original Backup
To prevent data loss if original IXW
media gets lost before backed up
Configuration to prevent Document Service

“too early” purging:
Purge only after “safety period“
– E. g. a week
– Grants enough time to react if
WORM backup fails
Make purge job respect
Buffer properties
the WORM backup
– Allows purging as soon as
one backup is made, Job command
even if multiple (local or argument -b
remote) IXW media backups
are configured Purge job properties

The explanations given above refer to IXW media. Using ISO media (CD, DVD, HD-WO, WORM),
the disk buffer does normally not play the role of a temporary backup since the ISO media backup
is written immediately along with the original (“synchronous” backup); the buffer purge
configuration has no influence on data safety here.
Nevertheless: If a ISO media backup shall be made
• in a second jukebox or
• at a later point of time,
the step sequence of writing to original, backing up, and purging from disk buffer is exactly the
same as for IXW medias (“asynchronous” backup). In these cases, disk buffer purging should
follow the same rules as for IXW medias, as explained above.
Making the buffer purging respect the backup

Purging the buffer can be made dependent on the existence of a document’s backup on a backup
IXW media; should the purge job encounter a document that has not yet been backed up, it does
not delete it from the buffer. This is the safest way to operate IXW media backup and buffer
purging.
To enable this function:
1. In the Admin Client, go to Jobs.
2. In the Edit Job dialog, append “ -b” to the disk buffer name in entry field Arguments.
3. Confirm the dialog.
8-6 710-97
Ways of caching documents
after writing to optical media
In disk buffer
Documents are kept in disk buffer for a longer period,
purged later by buffer purge job
In cache
See next slide …
Documents are moved from disk buffer to cache as soon as possible
(either by media write job or by buffer purge job)
Not at all
Documents are deleted from disk buffer as soon as possible
(either by media write job or by buffer purge job)
For storage scenarios that do not require fast retrievability of “fresh” documents
STORM
Document Service
(optional)
Disk buffer Cache

The Archive Server offers the above-mentioned methods to treat documents after they have been
written to their final storage location on optical media.
The decision whether or not to cache documents at all should be based on how the documents are
used: Immediately after they have been archived, will they be retrieved frequently by the users?
This will be the case, for example, for the following archiving scenario:
• Early archiving (= store for entry later) with workflow in SAP
Scenarios where documents are archived after users have finished working with them do not
strictly need this type of caching. This applies, for example, for the following archiving scenarios:
• Late archiving with barcode in SAP
• All kinds of data archiving (from SAP, MS Exchange, Lotus Notes)
If you have decided to cache documents, there is still the choice where to keep the documents for
that purpose: either in the disk buffer or in the cache. See the next page for a discussion about the
pros and cons of both possibilities.

Caching: in disk buffer or in cache?
Caching in Caching
disk buffer in cache
Documents remain available during storage No document access when media are offline
system outage
disk buffer
Retention precisely controllable Document flushing done by implicit mechanism

(document may become flushed before
Pro
users’ interest ceases)

Significant if available space is rather limited
If hardware allows to operate cache HD partitions without mirroring (e. g. using RAID 1):
“Expensive” “Cheap”
(large space for caching must be provided (large space for caching can be provided in
Pro cache
in the highly protected disk buffer) the unprotected cache)

Workload for buffer purging (depends on amount of buffered data):
High purging workload Low purging workload
(extended document retention in buffer → (minimized document retention in buffer →
data gets accumulated to high amount) low total amount of buffered data)

The table above reveals the relevant properties of caching documents either in the disk buffer or in
the cache.
As a conclusion, caching in the disk buffer is the more stable but also more expensive solution;
caching in the cache is cheaper but has drawbacks in certain situations.
8-8 710-97
Chapter guide

Backup
Caching
Sizing


Purge configuration examples
Required
Requiredav.
av.space:
space:100%
100%
IXW pool, Cache
no caching: Cachebefore
beforepurging
purging
Clear
Cleardoc.s
doc.solder
olderthan
thann/a
n/adays
days
with parameter "-b"
IXW pool, Required

Requiredav.
av.space:
space:100%
100%
Cache
Cachebefore
beforepurging
caching in cache: purging
Clear
Cleardoc.s
doc.solder
olderthan
thann/a
n/adays
days
Caching in disk buffer:

Required
Requiredav.
av.space:
space:10%
Purging by filling rate only 10%
Cache
Cachebefore
beforepurging
purging
– If disk buffer too small, documents are Clear
purged earlier than desired Cleardoc.s
doc.solder
olderthan
thann/a
n/adays
days
Purging by retention period only
– Setting without filling rate not
recommended
– If disk buffer too small, it may become filled
up
(→ no archiving of new documents possible
any longer)
Purging by filling rate + retention Required
Requiredav.
av.space:
space:5%5%
– Compromise between availability, Cache
Cachebefore
beforepurging
purging
retention, and purging workload Clear
Cleardoc.s
doc.solder
olderthan
than180
180days
days
The slide above illustrates examples how the rules for disk buffer purging in various situations —
discussed in detail on the previous pages — can be realized in terms of buffer purging options.
Some of these example configurations contain an “available space” requirement of 0%:
• This ensures that documents younger than 7 days are never deleted; this is reasonable
since this constraint is established for the sake of data loss protection.
• On the other hand, in the extreme case of the disk buffer being filled up with “younger”
documents, the purge buffer job will not delete anything; i. e, with this setting, the disk buffer
may possibly become completely full if it is too small to hold 7 days’ archiving data.
Therefore, using the 0% setting, it is the administrator’s duty to keep an eye on the disk
buffer filling rate (e. g. by means of the Archive Server Monitor) and to enlarge its disk
space if it becomes too small.
Using IXW medias, you should always enable the “respect WORM backup” property for buffer
purging; see page Disk buffer as temporary WORM backup (earlier in this chapter) for details.
8-10 710-97
Chapter guide

Backup
Caching
Sizing


Sizing considerations (1)
For ISO media (write-at-once)

Buffer must hold data to fill up one partition per assigned pool
– Using DVDs: 4.7 GB
– Using WORM: 4.6 GB
– Using HD-WO: variable up to maximum size (i. e. 1GB with HD-WO:1000)
– (Using CDs: 640 MB)
Add amount of data typically archived between two ISO write job invocations
– In case the last write job has missed just a little amount of data for burning a disk
Sizing example:
Used media type DVD

Number of ISO pools using the buffer 3
Write job schedule daily
Max. amount of data archived daily 500 MB
Min. disk buffer size 3 × 4700 MB + 500 MB = 14600 MB ≈ 14.5 GB

Certain storage systems support writing ISO images to a "virtual jukebox" in write-once mode (HD-
WO).
Consider limits of maximum file size supported by storage system.
8-12 710-97
Sizing considerations (2)
For IXW media (incremental writing)

Disk buffer serves as temporary backup. Typical retention period:
– until next purge job execution, usually 1 day
Min. size = amount of data typically archived into assigned pools within
backup period
For FS pool (single file) and VI pool

Depends on frequency of write job
Less critical than optical media, since final storage is also hard disk
For all storage systems

Add generous reserve to be prepared for media writing problems,
e. g. jukebox damage, storage system failure
If disk buffer is used as cache

Add total amount of data to be cached
(average archiving rate × retention period)

In case of media writing problems, no documents can be removed from the disk buffer; as a
consequence, documents queue up in the disk buffer as long as media writing is interrupted. As
soon as the disk buffer is filled up, archiving new documents is no longer possible.
In order to bridge the media writing downtime, it is reasonable to equip the disk buffer with
considerable space reserve. The bigger this reserve, the longer can archiving be continued.

Chapter guide

Backup
Caching
Sizing

8-14 710-97
Create diskbuffer (1)

You can create a New Original Disk Buffer as described:

Specify the Disk buffer name (unique among all names of disk buffers on this Archive
Server) and the Disk buffer Purge Configuration attributes as discussed earlier in this
chapter.
Purging the buffer is a periodic job that is to be scheduled here. First assign to the job a
name (the illustration shows a convention), then specify the job period. The illustration
shows a reasonable choice: once per night.
Notes:
– This job will later be visible and maintainable in the Archive Server Administration’s
Jobs section.
– Using IXW medias on an Archive Server, you should edit the job to make buffer
purging dependent on WORM backup; see page Disk buffer as temporary WORM
backup (earlier in this chapter) how to do this.

Create diskbuffer (2) –
Provide hard disk partition
Provide hard disk partition (Unix: a file system) on operating system level
To be used exclusively by the disk buffer
Otherwise, free space calculations will fail
Must be read/writable by the Archive Server processes
Do not make partition too large
Too many documents on a partition may lead to performance problems
– During disk buffer purging
– During volume consistency checks
If more total space required:
Use several smaller partitions instead of a single large one
– One partition can be assigned during disk buffer creation
– Additional partitions can be assigned later

To create a disk buffer, you first have to provide a hard disk partition on operating system level;
see the previous slides about how large this partition should be. On a Unix-based Archive Server,
make sure the root directory of the file system is owned by the user/group that the Archive Server
is operated as (e. g. ixosadm/ixossys) and has permissions 770.
The recommendation not to make the hard disk partition too large is due to the fact that some
administrative actions (like disk buffer purging or consistency checks) require examining the whole
partition contents. The more documents are stored there, the longer such a scan will take. If,
moreover, a partition is full of very small documents, the total number of files is very high; this may
lead to unacceptably long execution times of those actions. To prevent this type of problem, rather
use multiple partitions of moderate size instead of a single large partition. If you store rather large
documents only (like SAP data archiving files), the partition may be made larger as well; where
mainly small documents are stored, the partition size should be smaller (using BLOBs, however,
reduces the number of stored files of small documents).
If you choose to divide the total buffer space into more than one partition, you have to attach all but
the first partition to the disk buffer after the disk buffer has been created; see chapter Hard Disk
Resource Maintenance for more information.
8-16 710-97
Create diskbuffer (3)

Create a New Volume as specified in the previous slide.

Volume name: An (Archive Server -internal) logical name for the partition; must be unique
throughout all volume names (including IXW medias) of this server. The Archive Server will
henceforth maintain the volume by this name.
Mount path: The root directory of the partition’s file system. On Unix platforms, it is the
directory where the partition is mounted; on Windows, it may be a mounted partition or a
drive specification.
If, on a Windows-based Archive Server, you want to use a network share instead of a local
hard disk drive, see KC article
about how to do that exactly.
Use Attach Volume to assign the prepared hard disk partition to the disk buffer.

Assign disk buffer to media pool

A disk buffer must be chosen for each ISO or IXW pool already when the pool is created. To
assign a different disk buffer some time afterwards, invoke the Properties of the pool as
illustrated above and select one of the defined disk buffers from the list.
Whenever you assign a disk buffer to a pool, always consider that the settings for the media write
job and the settings for the buffer purge job interfere with each other; a reasonable writing and
caching setup must involve both setting groups. Refer to the Purge configuration examples pages
(earlier in this chapter) for more information.
8-18 710-97
One or more disk buffers?
Archive Server Storage System
Pools for log. archives Disk buffers
1 MyBuffer1
F1_Pool
Disk1
F2_Pool
Disk2
2
HR_Pool
MyBuffer2
3 Disk3
Configuration 1
Configuration 2

The term “disk buffer” shall not be confused with a hard disk partition for buffering data. Instead, a
disk buffer is a logical construct of the Archive Server— with certain properties — that one or more
hard disk partitions are assigned to.
1. If you have several logical archives with ISO or IXW pools, you may use a single disk buffer
(“MyBuffer1” in the above illustration) for them all.
2. To enlarge disk buffer capacity, an additional hard disk partition (“Disk2”) may be assigned
to that buffer. Thus you normally need only one diskbuffer, even employing multiple hard
disk volumes for buffering.
3. Alternatively, you may use a second disk buffer (“MyBuffer2”) with its attached hard disk
partition (“Disk3”).
Using multiple disk buffers is recommended only for situations where there is a real requirement
for this, e.g. if different disk buffer configurations have to be used at the same time for different
kinds of archived data. Refer to page Purge configuration examples (earlier in this chapter) for
more information.
However, as the number of logical archives increases, you will possibly run short of drive letters to
use on Windows OS.
Note: Due to Archive Server processing internals, it is more recommendable to enlarge disk buffer
space by extending the assigned hard disk partition (wherever possible) than to simply attach a
second partition.
Attention: It leads to severe problems on the Archive Server if you assign the same hard disk
partition to different disk buffers or to a disk buffer and cache at the same time!

Exercise: Create disk buffer
Create disk buffer

Assign to media pool
Archive sample document

8-20 710-97
9 Document Processing Options
Variants how the Archive Server treats

stored documents
Slide 1
Document Processing Options 9-1

Chapter Overview
Compression
Encryption
Blobs
Single instance
Delayed archiving
Cache enabled
Timestamps
Document Processing Options • Slide 2

This chapter introduces further possibilities to process documents, in addition to the “main”
document flow aspects discussed previously.
These document processing functions are not generally active on an Archive Server; instead, they
can be switched on or off individually for each logical archive (as illustrated above).
In addition to their activation, some of the functions obey further configuration parameters; they can
only be set globally on the Archive Server. Details are given on the following pages.
9-2 710-97
Compression
Shrinks size of document files on storage media, increases space

efficiency
Performed by media write job immediately before writing
In Write through (HDSK) pools: by dedicated job (command
Compress_HDSK)
zlib algorithm used
Affects files of certain type only
List can be extended in Archive Server Configuration
Other file formats are already compressed: FAX, JPEG, SAP data archiving
format
Decompression takes place immediately after
reading from storage media or Diskbuffer
Activation always recommendable

Before a Write job writes components to the storage media the compression takes place in the
Diskbuffer. Only specific types of files will be compressed. To add a new mimetype of files to be
compressed a new entry in the file Compr.Setup has to be made. This file is located in the Archive
Server Configuration directory. A change in Compr.Setup requires a restart of the Archive Server’s
processes. After a Write Job run the components are compressed in the Diskbuffer and on the
storage media.
In archiving projects all mimetypes of files that are worth compressing have to be examined and
added to Compr.Setup.
BLOB = Binary Large Object
In the filesystem that examine by the write jobs are marked with the prefix:
rd.<data file-name>, …

Encryption
Makes documents unreadable outside the Archive Server

Ensures document privacy in case of storage media theft
Effective on storage media only
Not in disk buffer (until Write Job has run), cache, network
For protecting privacy during client/server transmission: Use HTTPS
Performed by write job immediately before writing
In HDSK pools: by dedicated job (command Compress_HDSK)
AES Rijndael algorithm used
Encryption key must be created and maintained on Archive Server
See Archive Server Administration Guide for details
Recommendation: Do not activate unless required explicitly

Like Compression the Encryption is performed by the Write Job before the actual writing to storage
media takes place. This means that newly archived documents are stored unencrypted in the
Diskbuffer.
To set encryption use the Archive Server Administration Client.
To export or import the encryption key(s) use the command line tool “recIO”. You find this tool in
the folder “<OT install AS>\bin” .
9-4 710-97
BLOBs (1) – Properties
Containers for many small archived Configuration parameters (defined

files once per Archive Server)
On document components level Max. total size (default: 4 MB)
Store any kind of components, Max. element size (default: 40 kB)
including notes and annotations Max. no. of elements (default:
1000)
Effect: Storing few large files instead
of many small files Recommendable especially for high
archiving traffic with small document
Benefit: Optimizing storage of small
files
files
Minimize space fragmentation on Drawback: Documents stay in disk
storage media buffer unwritten as long as the BLOB
Reduce overhead of file system is still open
structure information Using IXW medias, this is probably
Speed up WORM writing longer than waiting for the next IXW
write job execution
Document component is appended to
BLOB as soon as it enters the disk
buffer
The sizing parameters for BLOBs — mentioned above — are maintained in the DS.Setup file. See
the Archive Server Configuration Parameters Guide (available in the Knowledge Center:
http://knowledge.opentext.com) for details.
A useful command line tool to work with BLOBs is “ixblob”. You find this tool in the Installation
Directory of the Archive Server in folder “bin”.
ixblob –p blob
ixblob –t[vms] blob [file …]
blob ≡ path\name of a blob file

-v ≡ verbose (German: ausführlich/wortreich)
-t ≡ list the content
-p ≡ print BLOB properties
-m ≡ sorteted by modification time
-s ≡ sorted by size
The open BLOBs can be seen in the Archive Server Runtime Files directory under
var\ds\temp\BLOBlog

BLOBs (2) – Tracing documents with dsClient
Components in BLOBs
will not be found here
PROMPT> dsClient localhost dsadmin password
If whole document is
buried in a BLOB, this
-> dinfo aaajclfhitjt32mqp3fmus5qglvzk
directory does not
docIdNo=944 path=96\76\000003B0 noOfComps=2 even exist
...
component type volume version
page1.fax FAX Diskbuffer_Part1 1
page2.fax FAX BLOB1000 1
This component is
buried in a BLOB
-> dinfo BLOB1000
docIdNo=1000 path=96\77\000003E8 noOfComps=1
...
docid=BLOBd032eb953e785acc47b4f720
... The traced component
component type volume version is actually stored here
BLOB BLOB Diskbuffer_Part1 1

If BLOBs are activated, document components can be “swallowed” by a BLOB, i. e. they are not
stored on storage media as they would be without BLOBs. The chart above explains how to trace a
document component’s storage location in this situation:
In the dinfo output of dsClient (see also chapter Document Structure on Storage Media), the
fact that a document component is buried in a BLOB can be recognized by the volume attribute
value BLOB.... You can then proceed by applying dinfo to the BLOB itself, as illustrated above;
this leads you to where the BLOB is actually stored on your server.
Note: Querying the DocumentService for a BLOB this way does only work if your dsClient
session is running on the Archive Server itself!
To close open BLOBs stop and restart the spawner process “dsaux“, e. g. type in on com-mand
line:
spawncmd stop dsaux
spawncmd start dsaux
9-6 710-97
Single instance (1) – Properties
Single instance also known as Special care has to be taken when
Single Instance Archiving (SIA) exporting media from the archive
Wrong proceeding may result in “dead”
To store content only once, even if references
the same file is sent to the archive
multiple times Benefit:
Identification of identical files by Space saving on storage media
SHA1 fingerprint (160 bits) Main target scenarios:
– archiving of e-mail attachments
Result – archiving of files
Single instance of stored file Useful in conjunction with:
→ the SIA target
– Email Archiving
Multiple references to stored file – File System Archiving
→ the SIA sources
– Stored as stub files with zero Drawback:
length in BLOBs Induces system overhead
Certain files are excluded Increases both processing work and
database volume
As they will never be identical
Useful only if there are more than at
least 2 references to a file
Should not generally be enabled

• Since the SHA1 hash value — used as fingerprint for an archived file — is 160 bits wide, the
probability of erroneous identification of two different files is 2-160.
• A reference count is maintained for a Single instance target: The target component is
deleted only after the last reference to it has been deleted.
• Single instance sources (= references to the really stored files) are maintained in the
storage database. However, in order to make the “normal” database import/export
mechanics of the Archive Server work for Single instance, they are also stored on the actual
storage media as stub files:
– With zero length (do not allocate storage space)
– Always in BLOBs, even in BLOBs are not activated explicitly in the given context (to
avoid storage overhead for the empty files)
– Never accessed for reading, except during a database export/import
• Certain files can be excluded from the SIA mechanism — i. e. they will always be stored
individually — if there is no probability that they are identical; this depends on the
application context. For example, every stored e-mail archiving from MS Exchange will
contain a component file called REFERENCES; such a file will never match any other one,
thus there is no need to apply SIA to it.
On the Archive Server, excluding files from Single instance can be configured:
– According to MIME type (for storing via HTTP)
– According to IXOS component type (for storing via RPC)
– According to component (= file) name
∗ Default: INFO.TXT, REFERENCES
(these files are never identical in MS Exchange)
This configuration is maintained in the Configuration Files SiaName.Setup and
SiaType.Setup

Single instance (2) –
Tracing Single Instance components
PROMPT>
PROMPT> dsClient
dsClient localhost
localhost dsadmin
dsadmin password
password This document contains
references to Single
->
-> dinfo
dinfo aaajfdvlg3pd32mqp3fphyoqglvzk
aaajfdvlg3pd32mqp3fphyoqglvzk
Instance Targets
docIdNo=945
docIdNo=945 path=96\76\000003B1
path=96\76\000003B1 noOfComps=2
noOfComps=2
...
...
status=0x4010(
status=0x4010( DB DB SIASOURCE
SIASOURCE ),
), archive=C0
archive=C0 Trace this
component
component type
type volume
volume version
version component
page1.fax
page1.fax FAX
FAX Diskbuffer_Part1
Diskbuffer_Part1 11
page2.fax
page2.fax FAX
FAX BLOB1000
BLOB1000 11
The target of this component
-> cinfo aaajfdvlg3pd32mqp3fphyoqglvzk page1.fax is physically stored as a
-> cinfo aaajfdvlg3pd32mqp3fphyoqglvzk page1.fax component of this Single
Component
Component page1.fax
page1.fax Instance Target document
...
...
status=0x4010(
status=0x4010( DB
DB SIASOURCE
SIASOURCE ))
pathName=H:\\.\96\76\000003B2\S0HA8W2M.SIA;1
pathName=H:\\.\96\76\000003B2\S0HA8W2M.SIA;1 (BLOB1000
(BLOB1000 ->
-> _SIA_aaajgcqbw5vd...)
_SIA_aaajgcqbw5vd...)
cacheName=F:\.\96\76\000003B2\S0HA8W2M.SIA;1
cacheName=F:\.\96\76\000003B2\S0HA8W2M.SIA;1
volName=Diskbuffer_Part1 The traced component is
physically stored here

If single instance archiving is activated, document components may be just references (“sources”)
to the actual files stored at a different location (“targets”). The chart above explains how to trace a
document component’s storage location in this situation:
In the dinfo output of dsClient (see also chapter Document Structure on Storage Media), the
fact that components of a certain document may be just SIA references can be recognized by the
document’s status flag SIASOURCE.
To clarify the exact status of a certain component, use the cinfo command for querying details
about this component. If the pathName attribute has a suffix (BLOB... -> _SIA_...), single
instance archiving has indeed been applied to this component. The true storage location of the
component file (the SIA “target”) is displayed as the first part of the pathName attribute.
9-8 710-97
Delayed archiving (1) – Concept
Scenario:
Retention period cannot be set leading
application during archiving
Different document types with different store document
Archive Disk buffer
retention periods w/ retention=EVENT
Server & deferred archiving
in one logical archive
Retention to be decided later
later:
How it works: set retention period
Storage & plan for DS job
Documents stored in Disk Buffer System (move to storage)
not written to storage subsystem (yet)

When retention known:
Using http API,
– set retention period &
– create DS job entry


Delayed archiving (2) – pool _DELAYED_
C:\test\write>dsh -h localhost
command: create -a A0 -f test.txt
1(-): command = create
1(0): ... call dsCreate
1(0): ... call dshDsCreateFile2
1(0): ... command succeeded
1(0): ...... docid = 'aaaaxozt4laeiteyvyacqreazcuma'
command: exit
Documents
stored in 2(-): command = exit
Disk buffer and 2(-): ... exit program
"parked" in
pool_DELAYED_
C:\test\write>dsCD -size
pool A0_A0pool contains 0 Mbytes
pool _DELAYED_ contains 0 Mbytes

When archiving with the option Delayed archiving, the document are stored in Disk buffer and
"parked" in pool _DELAYED_. Once the appropriate command is sent from the leading application,
documents will be moved to the correct pool for further processing to storage system.
9-10 710-97
Delayed archiving (3) – start archiving
C:\test\write>dsh -h localhost
command: setDocumentFlag -a A0 –d aaaaxozt4laeiteyvyacqreazcuma –S delayed
1(-): command = setDocumentFlag
1(0): ... call setDocumentFlag
1(0): ... command succeeded
command: exit
C:\test\write>dsCD -size
pool A0_A0pool contains 0 Mbytes


Cache enabled
Cache has to be created beforehand

or at least one volume has to be
assigned to the <Global Cache>
Cache enabled in the properties of
individual Logical Archives sets
read caching
If a component is located on the storage media
only it is copied to the Cache and delivered
from there to the client.
Different to caching on
Diskbuffer level
Cache before documents are purged from
Diskbuffer
Caching usually used for optical media

In the Administration Client a new Cache can created. See -> Infrastructure -> Caches. You do not
necessarily have to create a new Cache. It is possible to use the <Global Cache> which is the
default Cache instead. At least one Volume has to assigned to the new Cache or the <Global
Cache>.
When setting Cache enabled, be aware that this applies only to read caching. That means that i.e.
when documents are requested from an application for display, the displayed component(s) will be
cached in the assigned Cache only if these components are located on the storage media only.
When users request the component again, it can be retrieved quickly from the Cache. This setting
in the properties of individual Logical Archives affects only components belonging to that particular
Archive.
This is different to the caching setting for the Diskbuffer. Here the components can be moved to
the Cache before they are purged from the Diskbuffer. Enabling Caching on Diskbuffer level can
affect the components of multiple Logical Archives since a Diskbuffer may be shared by multiple
Archives.
9-12 710-97
Timestamps (1) – Properties
Documents are digitally signed (together with a timestamp) after

archiving
Enables validating document authenticity at any time later
Possible timestamp sources
listed in Archive Server Release Notes
Livelink Timestamp Server (uses computer clock)
– not recommended for legal purposes
Details:
Archive Server Time Stamp Service – Administration Guide
Archive Server - Administration Guide


Timestamps (2) – Signing a document
Timestamping System
Document
Hash value Hash value
Hash value
Hash value Attributes

Private
key
Signature
Attributes
Signature

The chart above illustrates the steps involved in digitally signing a stored document:
• As soon as the document has entered the DocumentService (i. e. it is stored in the disk
buffer or in a Write through (HDSK) pool), a hash value is calculated for the document.
• The DocumentService sends the hash value to the timestamp service. This service may be
the local timestamp server itself or an external timestamp service provider.
• The timestamp service forms a triple from the document‘s hash value, the timestamp of the
current time, and additional attributes, and creates a hash value for this triple.
• The timestamp service creates a digital signature from the triple’s hash value, using its
private key, and adds this signature to the triple.
• The complete quadruple — including the signature — is sent back to the DocumentService
and stored as an additional component of the document.
9-14 710-97
Timestamps (3) – Verifying a signed document
Document
Hash value
Hash-value
Hash value
Attributes
Signature Hash value
Public
key

The chart above illustrates the steps involved in verifying a digitally signed document. The whole
proceeding starts as soon as a user, currently viewing the document, requests verification in the
Archive Windows Viewer:
1. The Archive Windows Viewer calculates the hash value for the displayed document.
2. It retrieves the “signature quadruple” from the Archive Server and extracts the originally
stored hash value.
3. It compares the original and the stored hash value: If they differ, the document (or the
signature quadruple) has been manipulated in the meantime.
4. Next, the validity of the signature quadruple must be verified. For this, the client calculates
the hash value for the document’s stored hash value, the timestamp, and the additional
attributes.
5. The included signature is decrypted using the timestamp service’s public key, resulting in
the triple’s original hash value.
6. The two hash values of the triple — original and current — are compared. If they differ, the
quadruple has been manipulated in the meantime; otherwise the document authenticity is
verified.

Timestamps (4) – Renewal of Timestamps
≥≥ 99.6
.6
Electronic signatures & timestamps rely on cryptographic algorithms
Cryptographic algorithms and keys loose their security qualification in the
course of time
Availability and verifiability of certificates is limited
i.e. in Germany, often only ca. 5 years
Conclusion:
Electronically signed or timestamped documents can loose their evidence in
the course of time!
i.e. in Germany, defined by the Bundesanzeiger
Solution:
Use ArchiSig timestamps to renew electronic signatures & timestamps
– Even if original signature would not be valid anymore, renewal with ArchiSig can
"refresh" validity of signature
– Not only archive timestamps, but also validity of personal signatures on documents
can be prolonged this way
Timestamps can become insecure after a certain time (i.e. 5 years) due to the following reasons:
• Key length
• Algorithm
• Public key method
• Certificate becomes invalid
To avoid this the following needs to be done:

• Re-hash time stamp & build new tree out of hashed time stamps
• Get a time stamp for the new tree
9-16 710-97
Timestamps (5) – Verification Modes
Verification mode has to be selected to

enable Timestamps
Connection to Timestamp provider
has to be configured beforehand
Timestamps can not be disabled later!
Possible verification modes
Strict: If the timestamp is not valid or
does not exist, the document
is not delivered.
Relaxed: If the timestamp is not valid, the
administrator is informed and the document is
delivered
No timestamp verification

In a Relaxed timestamp verification scenario, you can set notifications to be informed about invalid
timestamp requests.

9-18 710-97
10 Document Lifecycle
Management Overview
Introduction into the concept of DLM
Slide 1
Document Lifecycle Management Overview 10-1

Document Lifecycle Management
DLM in Archive Server is

Retention Handling
Storage reorganization
Deferred archiving
Deletion hold
Audit trails
DLM in Archive Server is not

HSM implementation
Copying content between or within archives
DLM & retention settings should comply with company policies

From administrative perspective, only make settings that are coordinated with
the business requirements and policies within the company
Document Lifecycle Management Overview • Slide 2

It is important to understand what the intention of DLM is since DLM is often mixed up with HSM
(Hierarchical Storage Management):
The idea of HSM is to have content fast available when it is new or often used. In this case the
content is stored on a local disk; otherwise it is displaced to a slow media like a tape where storage
is much cheaper as on hard disks. Some HSM implementations provide multi level displacement.
But: Since the HSM mostly simulates a simple file system for an application, it is always the HSM
server which decides about displacements of content by own heuristics.
The intention of DLM is that the application at least classifies the content to determinate the
lifecycle. When dealing with business documents, only an application knows about needs
belonging availability of content or legal guidelines. In this manner Archive Server (starting version
9.6) provides these mechanisms for DLM: Deferred archiving (which could be treated as a first
step in the direction “application controlled HSM”), retention handling, storage reorganization which
is automatically needed when storing content with retention in container files (to be covered later)
and audit trails which is an important monitoring instrument in regulated scenarios.
10-2 710-97
Value of Records & Documents
Records/documents are a valuable

asset of a company
Retention
document Period
Documents can become a potential archived
liability for a company
At the same time documents can
depending on scenario,
become important for legal reasons get rid of records fast
Keeping documents beyond their

official retention often not desired
by companies value for value for
business legal purposes


Retention Management Layers
Open Text Enterprise Server

Leading Application
(Records Management)
- Open Text Enterprise Server
- Handles application specific requirements
- Records Management
- Knows the semantics of documents
- SAP
- Controls Retention Management
- PDMS
- Triggers Retention Handling
-…
Repository for all document related metadata
Open Text Archive Server

- offers Retention Handling (retention classes, …)
Open Text Archive Server - Reacts only to requests from leading applications
- Exclusively controls the storage systems
- Handles media backup, media migration
Different types of storage with/without retention periods

- Opticals (DVD, WORM, UDO)
Storage System - Hard disk based Storage Systems (CAS, NAS, SAN...)

Open Text Enterprise Server (" Livelink") can provide a Records Management module. It is
intended to support & trigger retention handling of Archive Server from the Livelink Enterprise
Server.
DLM & retention settings should comply with company policies. From administrative perspective,
only make settings that are coordinated with the business requirements and policies within the
company.
10-4 710-97
Archive Server – Retention Handling
Retention Handling
is provided by Archive Server
is triggered by leading application
Leading
Application
delete? delete?
Leading application:
sets retention period
denied! allowed
sets retention event
purges or destroys content
Archive Server Archive

assures that content can‘t be deleted Server
within retention period
delete!
does not automatically purge content
all actions are monitored in audit trails
Storage
System


Retention Handling – Exterior View
Document lifecycle (leading application view):
creation date: retention date:

2006/04/24 11:00:00 + 365 days = 2007/04/24 11:00:00
createDoc protected expired

retention period=365 days
Protected: document cannot be modified / deleted

Expired: document may be modified or deleted, but is not deleted automatically
Retention date: time when the document protection ends

Notes:
– Leading application is using the http API.
– Retention period is specified while document is being created.
– Retention date = creation date + retention period.
– Protection: no delete / modify.
– No dedicated action is taken at the time of expiration.
10-6 710-97
Retention period
Retention period:
Parameter for creation of a document or component
extension of create call
May be set by the leading application

If missing, the archive default value will apply
Allowed values:
X > 0 (interpreted as number of days)
Special values: NONE, INFINITE, EVENT
Default value is No Retention


Retention date
Retention date:
attribute of the document
set during the creation of the document (or the creation of the first component):
retention date = creation date + retention period
cannot be changed later

set during document creation
change only possible in certain scenarios
– event-based retention, delayed classification, volume migration
Stored in DS table ds_doc and in attribute file ATTRIB.ATR
* possible in certain scenarios (event-based retention, delayed classification, volume migration)

Retention Date Details:

• 4 byte unsigned integer
– Range: 1970/01/01 00:00:01 to 2106/02/07 06:28:06 (UTC)
• Special values for NONE, INFINITE, EVENT
• Retention date will be truncated to the maximum possible value if the given retention period
is too large
• Stored in DS table ds_doc and in attribute file ATTRIB.ATR
10-8 710-97
Protected documents
Retention protection:
Operation protected expired
Add new component allowed allowed

Delete document denied* allowed
Delete component denied* allowed
Update component denied* allowed
Update notes / annotations** allowed allowed
View document allowed allowed
* in non-compliance mode the DS administrator may modify/delete documents locally (dsClient)

When using Archive Server 9.6.1 with an installed patch EA096-078 or EA096-055, it is not
possible to delete a document when it has a retention protection. Even administrators using
command line tools are not allowed to delete the documents any longer (independent of
compliance mode).
However, earlier and later Archive Server versions (i.e. Archive Server 9.6.1 with Patch 087 /
Archive Server ≥ 9.7.1) return again to the behaviour as described in the slide.

Example for Retention – Time based
Example: Invoices need to be stored for 10 years due to tax laws
Stage 1: retention period = 10 years starts
Stage 2:
Document is created in Retention period expires
archive server
document archived
retention: 10years
Stage 1 Stage 2
within 10 years: after 10 years:
deletion blocked deletion allowed

Retention period of 3650 days is not the exact value for 10 years but used just as a simple
example. In real scenarios, you would also have to take into account such effects as i.e. leap
years.
10-10 710-97
Examples for Retention – Event & Time based
Example: According to industry-specific regulations,

product documentation needs to be kept 5 years after the product has
been phased-out
Stage 1: event-based retention

Stage 2: retention period = 5 years starts
Document is created in Stage 3:

archive server Retention period expires
document archived product phased-out

retention: event retention: 5 years
Stage 1 Stage 2 Stage 3

during product lifecycle: within 5 years 5 years after
deletion blocked after phase-out: phase-out:
deletion blocked deletion allowed

Deferred Archiving
One Step archiving

The „classical way“, long term storage
Using fixed retention period
Two Step archiving: Deferred Archiving

If a leading application changes the content very often and has to prevent
that the content is written to the backend storage.
If storage parameters (e. g. retention period) cannot be specified during
creation in an early archiving scenario.

With DLM there are new storage scenarios. Of course you can simply archive content without a
controlled lifecycle. On the other hand there is the deferred archiving feature which allows a two
step archiving. This mode is interesting in two cases, first i.e. a scenario where the application
deals with working copies which are change often or deleted sometimes and the application (i.e.
TCP) has to ensure that no content is written onto a read only media. This has two aspects: The
content would waste disk space and the content could compromise someone.
The other case is interesting when the application has not enough information about the document
during the creation time but has to provide a retention period which definitely is a creation
parameter. In this case the application sets the retention to “event based” and uses the deferred
archiving to specify the retention within a further step. Another scenario belongs to this case: When
archiving from SAP there is no chance to add a retention parameter to the ArchiveLink URL, so
retention has to be set in a further step.
10-12 710-97
Compliance Mode
Turning on Compliance Mode

enables Audit Trail
nobody may delete archived documents (with enabled retention settings)
Without Compliance Mode (and with enabled retention settings)

leading applications may not delete archived documents
Archive Server administrators may delete archived documents
Recommended to enable Compliance Mode when using

retention settings
Keep in mind that once set, Compliance Mode cannot be turned off!

When using retention features for legal purposes, it is usually advisable to turn on Compliance
Mode. Be aware that once you turn on Compliance Mode, you are not able to turn it off! Turn it only
on when you are sure that you want this feature.

Exercise: Retention Settings
Retention period
Set retention period to 2 days
Archive a document
Check document info in dsClient
Try to delete document with retention

setting
Repeat steps with Compliance Mode

10-14 710-97
11 ELS Architecture
The big picture –

Enterprise Library Services
Slide 1
ELS Architecture 11-1

Open Text Content Services (1)
Open Text Content Services
Enterprise Enterprise Enterprise

Library Services Process Services Connect
ELS Architecture • Slide 2

Enterprise Library Services are the Holistic Approach to Integrated Records, Metadata, Archiving,
and Storage Management
Enterprise Library Services are a foundation layer that enables organizations to consistently
manage retention schedules and compliance rules for business content throughout the enterprise.
Enterprise Library Services provides the critical foundation for a true enterprise-wide ECM
strategy. It allows organizations to manage content and metadata in a single, consistent manner,
regardless of which solution created the content; integrating with SAP applications, Microsoft
Office SharePoint, shared file systems and email servers, as well as the full range of Open Text
offerings.
The trusted repository enabled by Enterprise Library Services is a shared service for all content,
allowing organizations to set and enforce a single set of rules for managing and archiving content
in a consistent and compliant manner, meeting internal policies and regulatory requirements, while
at the same time significantly reducing storage costs.
11-2 710-97
Open Text Content Services (2)
Form the basis for Open Text’s next-generation content management

framework
Enable information workers to manage and exploit all content types in a
unified way
The foundation for a true enterprise-wide ECM strategy
For all applications:
SAP, SharePoint, shared file systems and email servers
Full range of Open Text offerings


Enterprise Library Services (1)
A holistic approach offering

Enterprise
Lifecycle management
Library Services
Records/retention management
Search
Auditing
Archiving and Storage
A new technology: Web Services

Web APIs that can be accessed by applications
.. to all OTC applications and solutions

.. to organizations managing their applications

11-4 710-97
Enterprise Library Services (2)
Runtime and Core Services
Enterprise Library Web Services API

Audit Search Authentication Content Rendition
Metadata & RM Services Services Service Services Services
Document Lifecycle Records Management Index & Search
Retention & Disposition Archiving & Storage Auditing
Backend
Metadata Full-Text Storage


Components of Enterprise Library Services
Web Services Enterprise Server and Modules
Runtime and Core Web Services Enterprise Server
Metadata and RM Web Services

Records Management
Search Web Services

Security Clearance
Web-Services
Enterprise Web Services

ELS
Classifications
Records Management Web Services
Directory Services
Security Clearance Web Services
Archive Web Services Archive Storage Provider

Content Archiving:
Administration Client Content Move
EL Service
Archiving and Storage
Archive Server
Monitor Server and Monitor Web Client
All components are included in

Timestamp Control Client
Document Pipelines (base, perl, *) as ONE deliverable

Runtime and Core Web Services

• Common services
– Deployment, Configuration, Authentication
– Triggers, Scheduler, …
Metadata Web Services

• Applications and item types
Records Management
Search Services
• Enterprise Administration Services
Archive Services
• ArchiveLink Interface
• Archive Administration Service
11-6 710-97
Runtime & Core Services
API Runtime
Runtime container for OT Web Services
Provide common infrastructure
Avoid dependency on an application server
Lightweight
Core Services
Public APIs, primarily Web Services and HTTP based protocols
Services and connectors to back-end systems (LES, Archive, etc.)
Internal services
Cluster support
Failover and load balancing
Implementation
Based on Java
Runs with Tomcat or SAP NetWeaver


Open Text ECM 10 Architecture
Applications, Solutions
Enterprise Share-
SAP Email ...
Connect point
Application Server (Tomcat, Netweaver)
ArchiveLink
Core Services
Web Service http

API
Data Trans.
Config
Audit
ELIB
Service Layer
Search
Authent.
Scheduler
Admin
Content
Archive Cont
Rendition
Service
Layer
Repositories
OT7
LES Archive ...
Search

Some ECM components might require additional features of the runtime environment. This might
make it necessary to deploy this into an application server.
11-8 710-97
Base Services
Base services of the API Runtime

Service Deployment
Authentication
Configuration
Scheduler
Logging
Job Executor (Priorization, Thread Control)
Trigger
Messaging (communication in a cluster)
Locking (Cluster Support)


The inner workings
Audit Service RM and Metadata Data Transfer Authentication Config

Search (WS) Archive Link (AL)
(WS) (WS) (WS + HTTP) Service (WS) Service (WS)
Data Transfer CAP

Search Service Audit Service EL Service Config Service
Service Service
LES Services Content Services
Search Engine Enterprise Server Archive

Search EL Service
DocMan Content
(Extractor) (+ WebUI)
OT7
User Records
Index Audit Audit
Management Management

11-10 710-97
12 Archive Administration
New ELS Administration Client
Slide 1
Archive Administration 12-1

Administration Tools – Overview
Archive Administration • Slide 2

12-2 710-97
Administration Client, Web Services, Repositories
Microsoft Management Console
Administration Client
Client
Archive Document RCS/

Server Model LES
Application Server (Tomcat, SAP NetWeaver)

Server
AS-WS EL-WS UAI-WS SR-WS CAP-WS

Repository
Archive Server Archive Server–

AdministrationServer Enterprise Server
Document Service


Administration Client – GUI Overview
TreeView
Pane
Result Pane
(splitted)
Action Pane

12-4 710-97
Administration & Monitoring
Configuration & Customization

Buffers, devices, media
Logical archives
and jobs,
Cache areas & cache server
Security settings
Maintenance
Backup, failover, recovery
Migration of documents or
media
Key store and certificates
Monitoring the system

Archive Server Jobs
Resources, processes
Notify in case of problems

Email, alert, SNMP traps
DPInfo
Monitor the document Pipeline


Where to find what – Archives, SAP, Security
.6.1
≤≤ 99.6 .1
.7.x
≥≥ 99.7 .x

12-6 710-97
Logical Archives (1)


Logical Archives (2)

12-8 710-97
Where to find what – Known Servers
.6.1
≤≤ 99.6 .1
.7.x
≥≥ 99.7 .x


Where to find what – Jobs, Scan Stations,
Notifications
.7.x
≥≥ 99.7 .x
.6.1
≤≤ 99.6 .1

12-10 710-97
Events and Notifications
Notifications can be sent in case of important events
Configure which
event filter may
cause a
notification
Components sending events:

- Administration Server
- Monitor Server
Notification assigned
- Document Service
to event „Cache
- Storage Manager
Server Request - Timestamp Server
If the event occurs,
Error“
the notification will - High Availability
send an alert. - Volume Migration
- BASE Doctools
- SAP Doctools


Notify the Administrator in case of a problem
Message catalogs
ADMS_EN.cat Events
Assigned notifications
If a problem occurs:
Module sends message
Message
severity 1.Read message by 2.Determine all the 3.Determine the 4.Execute the
msgclass $msgcode from events matching corresponding notifications
component catalog the conditions notifications
msgcode
time
Notification Server
msgparams
dflttxt
Alert Email Tcl Script Write to file SNMP Trap
Message Text: Mail host: Tcl Script: Filename: Trap Receiver:

Sender address: Format: TCP/IP Port:
Recipient address: Message Text: Max File Size: Community:
alrt_create_entry Subject:
Message Text: Message Text:
Message Text:
Trap receiver
Administration Server Mail server
Script File Archive Administration • Slide 12
12-12 710-97
Where to find what – Utilities
.7.x
≥≥ 99.7 .x
.6.1
≤≤ 99.6 .1


Where to find what – Configuration Settings
.6.1
≤≤ 99.6 .1
.7.x
≥≥ 99.7 .x

12-14 710-97
Track processes through Web Monitor


MonitorServer and WebMonitor
☺
WebMonitor 3rd party
Monitor Systems
SNMP get SNMP get
MonitorServer
Management Information Base
com jbbox dpt dpq procstatus …
built-in component types
Scripts STORM DocumentPipeline File System Database Spawner DocumentService
Processes to be monitored

12-16 710-97
Logging of Administration Client
Set Log-Level in GUI
Default Location
– C:\Documents and Settings\<User>\Local Settings\Temp
Files
– AdminEL.log
– AdminEL-LEA.log
– AdminEL-Library Customization.log
– AdminEL-UAI-LIBRARY.log


12-18 710-97
13 Archive Server Startup and
Shutdown
Starting and stopping Archive Server
safely
Slide 1
Archive Server Startup and Shutdown 13-1

Components of Enterprise Library Services
Web Services Enterprise Server and Modules
Runtime and Core Web Services Enterprise Server
Metadata and RM Web Services

Records Management
Search Web Services

Security Clearance

Classifications
Records Management Web Services
Directory Services
Security Clearance Web Services
Archive Storage Provider

Archive Web Services Content Archiving:
Administration Client Content Move
EL Service
Archiving and Storage Services
Archive Server
components in a
Monitor Server and Monitor Web Client
standard Archive Server
Timestamp Control Client only scenario
Document Pipelines (base, perl, *)
Archive Server Startup and Shutdown • Slide 2

The Enterprise Library Services provides a flexible platform with variety of options and features.
However, for a standard Archive Server only scenario mainly the Archiving and Storage Services
along with some Web Services (mainly Runtime and Core Services) is needed.
More complex products and solutions may require further components and modules.
13-2 710-97
ELS Archive process layers
Tomcat//SAP
Tomcat SAPNetweaver
Netweaver
Monitor
Monitor Administration
Administration Document
Document
server
server server
server service
service
Startup Migration Notification Document

Shutdown
Migration Notification Document
order server
server server
server pipeline
pipeline order
Storage Manager
Storage Manager STORM
STORM
ArchiveSpawner
Archive Spawner
Archive and Storage Services
Archive and Storage Services
Databaseenvironment
Database environment

When you run the Enterprise Library Services (ELS) for archiving proposes only, you will have
services running:
•Your database service(s) for the ECR instance
•Tomcat or SAP Netweaver service(s) for the ELS Runtime and Core Services
•a Spawner service for the Archiving and Storage Services.
The three layers of processes are started up and shut down separately. However, this does not
mean that they may be started up and shut down independently from each other; the spawner
layer depends on the availability of the underlying layers.
When the whole machine is booted or shut down, it is ensured that all Archive Server processes
are started/stopped in the proper order. When performing a manual startup or shutdown — e. g. for
backup or maintenance reasons — or when developing your own startup/shutdown scripts,
however, you have to obey the startup/shutdown order displayed above.

Different types of spawner shutdown
“Full” shutdown “Stopall” shutdown

Spawner and all its children are All “active” processes are terminated
terminated Spawner itself is kept alive
All maintenance work possible Virtually all maintenance work possible
Very few reconfigurations require full
spawner shutdown
No process status information available Process status information still available
Useful for checking shutdown success
How-to How-to
spawncmd exit spawncmd stopall
Stop spawner service by OS Archive Server Administration: Menu
means File → Spawner → Stop
Archive Processes
Requires “full” startup afterwards Requires “startall” startup afterwards
How-to: Start spawner service by How-to: spawncmd startall
OS means No “full” startup — spawner itself is still
running!
Knowing the difference between the two variants of shutting down the spawner is essential for
being able to use the different ways of startup and shutdown, explained in this chapter.
Generally, the “stopall” shutdown method is the more “gentle” one; it keeps the spawner itself
running, yielding the considerable advantage to provide process status information during the
shutdown period. This is useful because, especially on Unix platforms, many spawner-controlled
processes terminate asynchronously, i. e. they are still alive when the shutdown command
(whichever you have chosen) returns. Being able to check when all processes have terminated
(using spawncmd status, see later in this chapter) is therefore an essential tool for setting up
your own maintenance tools, e. g. scripts for offline server backup.
For this reason, you should prefer using the “stopall” shutdown — combined with the “startall”
startup — wherever possible.
13-4 710-97
Startup and Shutdown on OS level (Windows)
Command line
Startup:
net start OracleServiceECR or net start mssqlserver
net start Oracle<ORA_HOME>TNSListener (only Oracle data base)
net start spawner
net start tomcat5
Performs
Performs aa
Shutdown: “full”
“full” shutdown!
shutdown!
net stop tomcat5
net stop spawner
net stop Oracle<ORA_HOME>TNSListener (only Oracle data base)
net stop OracleServiceECR or net stop mssqlserver
Using the Windows Services panel

Start/stop in the order
displayed above
Using MS SQL Server
instead of Oracle:
Service MSSQLServer

The <ORA_HOME> placeholder mentioned above represents the Oracle Home name of your Oracle
DBMS installation; it has been defined during the Oracle installation routine. In case you are
unsure what the actual value of this parameter is, simply open the Windows services list; you will
easily recognize the name by having a look at the Oracle services mentioned there.
Stopping the OracleServiceECR without explicitly shutting down the database instance before
causes no problems but leads to annoying warning messages in the Oracle trace file. In order to
keep your trace files clean, you may insert the following command in an archive shutdown script
right before the “net stop OracleServiceECR” command (given in cmd syntax; be sure to enter it as
one single line):
(echo connect internal/<passwd> && echo shutdown immediate) | svrmgrl

Checking status after startup (1):
DS database operation
Execute command DBTest in command line shell
# DBTest
...
trying to connect
...
connected
“connected” → Everything okay,

database running and accessible
Some error message → Database not accessible;
investigate this

DBTest is a database connection testing tool provided as part of the Archive Server installation.
DBTest tries to access the DS database exactly the same way the “productive” Archive Server
components do, e. g. document service and administration service.
If you have problems starting up the archive system but DBTest succeeds, you can be sure that it
is not the database that is causing the problem. Reversely, if this database test does not finish with
the “connected” message, you can be sure that the spawner-driven archive processes will not
come up properly.
13-6 710-97
Checking status after startup (2):
Spawner layer
Execute command spawncmd status in command line shell
C:\> spawncmd status

Terminated
Terminated irregularly
irregularly
(exit code ≠≠ 0)
(exit code 0) program-id sta pid start time stop time
------------------------------------------------------------
Log
Log file
file name
name similar
similar Clnt_dp R 526 07/24/2002 13:47:31
to program-id
to program-id admsrv T 1 07/24/2002 13:47:31 07/24/2002 19:21:47
bksrvr R 178 07/24/2002 13:47:31
cfbx R 507 07/24/2002 13:47:31
chkw T 0 07/24/2002 13:47:35 07/24/2002 13:47:35
cpfile R 328 07/24/2002 13:47:35
db T 0 07/24/2002 13:47:35 07/24/2002 13:47:36
doctods R 336 07/24/2002 13:47:36
dsrc1 R 353 07/24/2002 13:47:38
dsstockist T 0 07/24/2002 13:47:38 07/24/2001 13:47:39
dswc R 348 07/24/2002 13:47:38
jbd S 345 07/24/2002 13:47:55
These are allowed rfcS46 R 397 07/24/2002 15:10:56
to be terminated stockist T 0 07/24/2002 13:46:45 07/24/2002 13:46:47
with exit code = 0 testPort T 0 07/24/2002 13:46:40 07/24/2002 13:46:41
If more than the allowed ones are terminated

→ Something’s wrong; consult their log files

The best way to check whether the archive system startup was successful is the spawncmd status
command. The information presented in the status column (“sta”) of the resulting process list
means:
S Process is currently starting up
R Process is running
T Process is terminated
In a sane operational state, all archive system processes listed in spawncmd status have to be
running — except for the ones marked in the chart above. (However, not all of them may be
present, depending on your Archive Server release and operating system type; if you do not see
one of them at all, this is no problem.) If any of the other programs is marked as terminated,
something irregular has happened to it. To investigate this, you will have to have a look in the
corresponding log file. Each of the listed programs writes to a log file whose name is similar, yet
not always exactly equal, to the displayed program name. Some important examples:
admsrv → admSrv.log
dsrc1 → RC1.log
dswc → WC.log
As mentioned earlier in this chapter, the spawncmd status check is also possible after a
shutdown has been made using spawncmd stopall. In this situation, use the check to make
sure all processes are listed with status T before going on (making a backup, starting up again, or
taking other actions).
On a scanning station with EnterpriseScan installation, a subset of the server processes is
installed and must be running as well. There, stockist is the only program that is allowed to be
terminated during normal operation.

Runtime and Core Services in
ELS Administration

The Runtime and Core Services run within the Apache Tomcat or SAP Netweaver service.
13-8 710-97
STORM caveats
Stopping the spawner implies stopping STORM

STORM needs some time to finish startup or shutdown properly
Upon startup, WORM filesystem database must be opened
Upon shutdown, media drives must be unloaded
Normally finished within a minute
⇒ Starting/stopping without waiting until the previous stop/start
is completed may cause STORM to hang!
To be on the safe side, obey some rules:
Check for completion of startup/shutdown before going on
– Preferably use spawncmd stopall, spawncmd startall
instead of starting/stopping the spawner service
– This way, spawncmd status works even after shutdown
Before simply restarting the spawner in case of problems,
consider other methods of troubleshooting

The Storage Manager (STORM) is a part of the Archiving and Storage Services that run within the
Archive Spawner. It is responsible for storage sytem and jukebox related components of the
Archive Server.

Exercise: Shut down and start up
your Archive Server
Shut down and start up again the

processes of your Archive Server
Try different ways to do this
During this, monitor the processes’

operational status

13-10 710-97
14 Archive Server Monitoring
Detecting problems in time
Slide 1
Archive Server Monitoring 14-1

Chapter guide
Fundamental monitoring tasks and tools
Monitor Web Client

Job protocol
Advanced monitoring methods

Notifications
Scriptable monitoring tools
Integration into external system management tools
Archive Server Monitoring • Slide 2

14-2 710-97
Parameters observed by the
Monitor Web Client
http://<server>:8080/w3monc/
Operational status of
system processes
(running/terminated)
Document Service
Storage Manager
Document Pipeline
…
Storage space
Media pools
Hard disk buffers
Document pipeline
Database
Document Pipeline
processing errors
Requests for reading from
unavailable volumes
The Monitor Web Client supports the timely recognition of problematic conditions within the
system. It also monitors the Document Pipelines on the Archive Server and on scanning
workstations.
The state of the observed parameters is visualized in a three-level scheme: normal, warning, error.
In addition, each parameter can be accessed in the detail view.
Multiple Archive Servers may be monitored at the same time. This also includes the scanning
hosts (with Enterprise Scan installed and used) — the Monitor Web Client then reveals processing
errors within the Document Pipelines of the scanning station.
It is necessary to install the Monitor Service on the Enterprise Scan Client and also on the
Document Pipeline Servers to monitor this stations with the Monitor Web Client.

MonitorServer and WebMonitor
☺
WebMonitor 3rd party
Monitor Systems
SNMP get SNMP get
MonitorServer
Management Information Base
com jbbox dpt dpq procstatus …
built-in component types
Scripts STORM DocumentPipeline File System Database Spawner DocumentService
Processes to be monitored

14-4 710-97
Review job messages and job protocol
Job protocol
list
Messages
for a specific
job

The only important status information not provided by the Archive Server monitoring tools is the
execution results of the periodic jobs run by the Archive Server scheduler. To monitor those results
(in order to detect any problems), open the Job Protocol tab of the ELS Administration as
illustrated above. Error conditions are indicated by an icon with a "red block" in the protocol list.
In order to get further information about what has gone wrong, you may choose a job entry from
the list and check the Messages at the bottom.
You may also check <Archive root>\var\log\messages\*.*

Change Protocol Settings
Open Server Configuration in Administration Client

Runtime and Core Services → Configuration → Archive Server

14-6 710-97
Chapter guide
Fundamental monitoring tasks and tools

Monitor Web Client
Job protocol
Advanced monitoring methods
Notifications
Scriptable monitoring tools
Integration into external system management tools


Events and Notifications
Notifications can be sent in case of important events
Configure which
event filter may
cause a
notification
Components sending
events:
- Administration Server
- Monitor Server
- Document Service
Notification - Storage Manager
assigned to event - Timestamp Server
„Cache Server If the event occurs, - High Availablity
Request Error“ the notification will - Volume Migration
send an alert. - BASE Doctools
- SAP Doctools

14-8 710-97
Notify the Administrator in case of a problem
Message catalogs
ADMS_EN.cat Events
Assigned notifcations
If a problem occurs:
Module sends message
Message
severity 1.Read message by 2.Determine all the 3.Determine the 4.Execute the
msgclass $msgcode from events matching corresponding notifications
component catalog the conditions notifications
msgcode
time
Notification Server
msgparams
dflttxt
Alert Email Tcl Script Write to file SNMP Trap
Message Text: Mailhost: Tcl Script: Filename: Trap Receiver:

Sender address: Format: TCP/IP Port:
Recipient address: Message Text: Max File Size: Community:
alrt_create_entry Subject:
Message Text: Message Text:
Message Text:
Trap receiver
AdministrationServer Mailserver
Script File Archive Server Monitoring • Slide 9

Scriptable monitoring (1): ixmonTest
Windows: ixmonTst
Find out end number name corresponds to list position

by trial and error in Archive Server Monitor
> ixmonTest walk 1 300

1: name= "BackupServer-bksrvr"
value= "0 =Active = =1059115813 =Ok "
...
82: name= "DocService-unavail"
value= "50 =Warning = =1059116578 =Unavailable volumes:1 "
...
263: name= "DS Pools-Arch01_IXW"
value= "96 =Error = =1059116878 =No writeable partitions: ...
...
265: name= ""
value= ""
No more value indicates

items follow item status

ixmonTest (on Windows: ixmonTst) is the command line equivalent to the Archive Server Monitor.
As illustrated above, it outputs the requested status information in textual form, ready for being analyzed by
external text processing tools (like grep and perl). You can use it to implement your own monitoring
routines, for example to raise notifications in whatever situation may be important for you.
Some hints on using ixmonTest:
• The utility is installed on the Archive Server only, not — together with the Archive Server Monitor —
on the administrator workstation. However, you can use it via the network; for this, call it as
ixmonTest -h <host> .... (This way, you can monitor several Archive Servers centrally from a
single server.)
• The monitored status items are arranged as an enumerated list. With the ixmonTest arguments
walk <start> <end>, you select a certain range from this list. However, for a full monitoring the
only reasonable choice is retrieving the whole status list.
On the other hand, the status list has a variable length; it depends on the installation and
configuration of your server. The best way to determine the exact end number is calling ixmonTest
manually and trying different numbers until you see “empty” items at the list end.
• An item’s status (okay, warning, or error) is expressed as a numerical value: 0 means okay,
everything else indicates a problem. (Do not rely on the warning and error values to always be the
ones shown above; they may vary depending on the type of problem.)
• For a selection of what is interesting for your notification routine, you can refer to the name attribute
included in the output status list.
The following is a simplistic but, nevertheless, complete example shell script that uses ixmonTest; it sends
an e-mail whenever it finds a monitored item with a (non-empty) status other than zero:
# first check that we don't miss any status list items
if ! ixmonTest walk 300 300 | grep -q 'name= ""'; then
echo "Too many status items!" | mail -s Problem operator@mycomp.com
fi
# now examine the monitoring output for non-okay items
if ixmonTest walk 1 300 | grep -q 'value= "[^0"]'; then
echo “Problem on eCONserver!" | mail -s Problem operator@mycomp.com
fi
This script is meant to be executed as a cron job (every five minutes, for example) on the operating system.
Feel free to amend the script to an arbitrary level of complexity to exactly suit your needs.
14-10 710-97
Scriptable monitoring (2):
Scheduled jobs protocol
Protocol entries to be queried from storage database:

SQL> select * from ADM_JOB_PROTOCOL where STAT <> 'INFO';
JOBNAME STAT ... MESSAGE
------------- ----- ... ------------------------------------
Purge_buffer1 ERROR ... dshdskrm failed; program exit with 1
... ... ... ...

For scripted monitoring, it is also necessary to retrieve status information about success or failure
of scheduled jobs on the Archive Server (see also page Review job messages and job protocol
earlier in this chapter). This information is stored in the storage database ECR and can therefore
be retrieved by a suitable database query; see the above illustration for details.
Here is a simplistic but, nevertheless, complete example shell script — assuming Oracle as
database platform — that sends an e-mail whenever it finds a protocol entry indicating a job failure:
if echo "select 'num_errors', count(*)
from ADM_JOB_PROTOCOL
where STAT <> 'INFO';" \
| sqlplus -S ecr/ecr | grep -q 'num_errors.*[1-9]'
then
echo "Failed jobs found!" | mail -s Problem operator@mycomp.com
fi
(On a Unix-based Archive Server, this script has to be executed under the user account that the
database is executed as; it is normally named oracle.)
Again, this script is most useful if executed periodically on operating system level.

14-12 710-97
15 Handling Optical Archive Media
Daily operating tasks
Slide 1
Handling Optical Archive Media 15-1

Possible states of optical archive media
In device
Known to
Online (= readable)
storage database
Original volume …
… read/writable G
D Removed
… read-only F from jukebox
E
Original volume offline
A Backup volume
Empty Exported
B C from database
Uninitialized
(Not part of this chapter)
Bad volume
Handling Optical Archive Media • Slide 2

The chart above gives an overview of the different ways the Archive Server may regard optical
media.
Note that “being present in a jukebox (or single drive) device” does not mean the same as “known
to the storage database”; either combination of these two state properties are possible.
Media may move from one state to another. Some of these state transitions may happen without
manual interference, others require to be done by operating personnel. Those transitions relevant
for operating are labeled above:
A Filling an empty ISO medias with data and setting it to online, read-only, is done
automatically by a periodic ISO write job.
B Each new IXW media volume must be initialized for writing and reading. This can be done
either manually by the operator of automatically by the IXW write job.
C Likewise, backup IXW medias have to be initialized.
D After a IXW media volume has been filled up to the desired amount, it can be finalized
which sets it to a permanent read-only state.
E As soon as a IXW medium has been filled up with data and its backup has been
synchronized, the backup has to be taken out of the device and to be stored safely away.
F When the jukebox becomes full, the operator can make room for new media by taking “old”
ones out and storing them at a safe place.
G In case an Livelink client requests to read a document from a taken-out medium, it is the
operator’s duty to re-insert that particular medium into the jukebox.
The following pages present details about how to perform each of the mentioned transitions.
15-2 710-97
Regular tasks when using ISO Medias
Insert blank ISO medias into jukebox

Monitor server for newly burned disks
In job protocol
Receiving notifications
In volume lists of pools or jukeboxes
When a burn job has finished:
(Using double-sided DVDs:
wait until both sides are completed)
Take original and backup disk out of the jukebox
Label them with their volume name Re-insert
– Name is automatically assigned by burn job after
Re-insert original disk into jukebox labelling
Store backup disk safely away
Store in IXOS_FI_0001 IXOS_FI_0001

a safe
Backup Original
To provide empty ISO medias to the Archive Server , you simply insert them into the jukebox.
Whenever a disk (or a set of disks: original and backup) is to be burned, the Archive Server will
automatically choose an empty one, assign a name to it, and attach it to the corresponding ISO
pool.

Regular tasks when using IXW Medias
Provide empty IXW medias

Insert blank IXW media
Initialize both sides
Repeat for backup IXW media
Assign them to the
designated pool
Remove full backup IXW

medias from the jukebox,
store at safe place

Unlike ISO media volumes, IXW media volumes must be initialized and assigned to a IXW pool
before documents can be written to them. Initializing a IXW media volume basically includes giving
it a name (for a reasonable naming convention, see page IXW media naming scheme later in this
chapter); the above chart illustrates how this is accomplished using the Archive Server
Administration.
Notes:
• Since IXW medias comprise two volumes, each of them must be initialized separately.
• A IXW media backup volume must be initialized with the same name as the original volume;
the archive system recognizes the relation between them by the name correspondence.
• See later in this chapter how IXW medias can be initialized and assigned to a pool
automatically.
Backup IXW medias have to be kept in the jukebox as long as data is still written to the original
medium (since the backup is synchronized incrementally). The point of time when to remove the
backup IXW media can be recognized by the status display for the original (as illustrated above):
‘F’ means full, i. e. no more data will be written to it. Then it is time to store away the backup IXW
media.
15-4 710-97
IXW media volume assignment to a pool
Priority = order in which volumes of a pool are filled with data

Smallest priority value = filled first
IXW media jukebox must flip disk in order to access reverse side
Set priorities so that two sides
of the same disk are not adjacent
(not numerically consecutive)
→ Avoids too much disk flipping in jukebox Side A: 1
Priority values
Filling order
Disk 1 Side B: 3
Side A: 2
Disk 2 Side B: 4

Since IXW disks are double-sided but IXW drives can access only one of them at a time, the
jukebox robot must turn the disk whenever the reverse side shall be accessed. For this reason, it
would be inefficient to begin filling the second side of a IXW media immediately after the first side
has been finished: Read requests for recently archived documents would be directed to the first
side whereas write requests for newly arrived documents would require the second side — this
would result in very frequent disk flipping.
If the jukebox has enough drives, it is better to distribute the filling order evenly to two (or more)
disks as illustrated above. That way, it is possible that the two disk sides currently under frequent
access (the one just finished and the one just begun) stay in different drives for a longer period,
allowing fast access to all currently prominent documents.
To accomplish this method, you always have to initialize and assign two IXW medias at the same
time (plus two backup IXW medias), possessing four different volumes altogether.

IXW media naming scheme
Whole IXW media must be identified uniquely

Two sides must be distinguished
Affiliation to logical archive should be recognizable
Sequential number should have fixed number of digits
Proposal:
IXW media: <archive_id>_<seq_no>
Side A: <archive_id>_<seq_no>A
Side B: <archive_id>_<seq_no>B
FI_0001A
FI_0001
FI_0001B

An Archive Server does not raise any constraints about IXW media volume names (except for a
length limitation to 32 characters) — therefore, you should set up a naming convention at the very
beginning of Archive Server usage; the above chart gives a reasonable proposal.
Labeling the IXW media is done the following way: The IXW media as a whole is labeled physically
by writing the name on the case; the IXW media sides — i. e. volumes — are only labeled by
assigning the side names electronically during initialization. It does not matter which side is
initialized as ‘A’ or as ‘B’; the jukebox is capable of detecting this automatically.
Notes:
• Including a date in the name does not make very much sense — you have to assign the
name before the IXW media usage begins, i. e. at a time when you do not yet know when
the IXW media filling will be finished. Even if you intend to interpret the date as the ending
date of filling the previous IXW media : You will initialize the IXW media before the previous
one is completely filled, not being able to precisely anticipate when it will have been
finished.
• It is best to use a fixed number of digits for the sequence number (four will always be
sufficient); this makes it easy to order IXW media lists numerically in the Archive Server
Administration display.
15-6 710-97
Automatic IXW media initialization
Initialization and pool assignment can be done automatically

Including backup IXW medias, if backup option enabled
See KC about setting
the sequence counter
Proceeding
IXW media write job checks
availability of assigned
“empty” IXW medias
after invocation
– “Empty” = filled to less
than 5% (changeable)
If not enough assigned
“empty” IXW medias are
found, new ones are initi-
alized and assigned to pool
Then writing from disk buffer
to IXW medias is started
The naming pattern for automatic IXW media initialization may contain certain placeholders which
are replaced by actual values in the instance of WORM initialization. These placeholders include:
$(ARCHIVE) Logical archive name
$(POOL) Pool name
$(PREF) Name prefix as defined in Archive Server configuration (default: “IXOS”)
$(SEQ) Sequence number (mandatory)
$(YEAR) Date and time variables
$(MONTH)
$(MDAY)
$(HOUR)
$(MIN)
$(SEC)
$ENV(varname) Value of environment variable “varname”
(The parentheses around the placeholder names are not strictly necessary, but you will almost
always need them to separate placeholder names from other name pattern elements properly.)
Change AS.ADMS.JOBS.AUTOINIT.ADMS_IFS_INIT_EMPTY_PERC_USED if you will have a
different value then 5 % by default for an empty media.
When you activate the automatic initialization the first time for a certain pool, it will count the
initialized IXW volumes beginning at 0; this is undesirable if you have already got manually
initialized IXW medias in that pool. You can explicitly set the sequence counter to a defined starting
number in order to continue the numbering of the already present IXW medias; see ESC article
Check / Set the sequence number of the next IXW media to be burned
(https://knowledge.opentext.com/knowledge/llisapi.dll/open/15530356) for details.

IXW media finalization (1): Properties
When a IXW media volume is filled up, it may be finalized

Filesystem structure data is moved from STORM’s filesystem database onto
the WORM volume itself
– Keeps WORM filesystem database small
IXW media becomes read-only ISO filesystem
Backup IXW media is finalized automatically
– As soon as finalized original is backed up
Finalization may fail in rare cases
– WORM filesystem database must keep structure data “forever”
– Nevertheless, IXW volume remains read-only

15-8 710-97
IXW media finalization (2): Usage
Manual execution Automatic execution

Per volume As part of IXW write job
For all IXW medias of a certain pool, Rules: Filling rate, date of last writing
selected by
– filling rate
– date of last writing

The choice between the two variants of doing the finalization — automatic or manual — is rather a
matter of operating preference; both lead to the same result.

When the jukebox(es) are filled up
Full media have to be taken out of the jukebox

and stored at a safe place
→ Media are offline
For this, choose media containing documents not often needed
E. g. oldest first
E. g. least-recently-accessed first
– Retrieve dates of last read access for all media with: cdadm survey -v +oL
Documents remain known to the archive database,

can be retrieved again after re-inserting
corresponding volumes into jukebox → next slide
Trying to retrieve an offline document, user gets message:

“Volume … is offline.”

There are two stages of removing documents from Archive Server:

• Just taking media out of the jukeboxes to make room for new ones, still keeping documents
on those media archived but not retrievable online
• Permanently removing media containing expired documents (see second-next page)
The cdadm survey -v +oL command delivers a list of all archive volumes and their dates of
last read access. Unfortunately, it expresses the dates as the number of seconds since the Unix
epoch, which is hardly human-readable. However, you may filter the list through the following Perl
script in order to obtain a readable form:
while ( <> ) {
if ( /(^\w+[ \t]+)(\d+)/ ) { print $1 . (scalar localtime $2) . "\n"; }
else { print; }
}
(This is easily possible even on a Windows-based Archive Server since Perl is included in every
Archive Server installation.)
15-10 710-97
Re-inserting offline media
into the jukebox on demand
Archive ServerMonitor indicates

request(s) for offline volumes
Archive ServerAdministration
identifies volumes to be provided

As soon as the jukebox(es) have been filled up with used media, older media must be taken out in
order to make room for new empty ones; such media no longer present in a jukebox are called
unavailable or offline. Afterwards it may happen that some Archive Server user requests a
document from an offline volume. The user then gets a message that this document is currently
offline. The Archive Server Monitor, in turn, displays a warning notice at item
“DocService”→“unavail”.
In such a situation, it is the operator’s duty to re-insert the requested disk into the jukebox. To learn
which volume(s) are affected: Within the Devices section of the Archive Server Administration,
open the Unavailable volumes window as illustrated above; this window reveals the volume
names in question.

15-12 710-97
16 Media Migration
Migration of storage media in
Archive Server
Slide 1
Media Migration 16-1

Chapter guide
Media migration: general aspects
Doing the migration

Involved steps
Additional features
Document migration
Media Migration • Slide 2

16-2 710-97
Introduction
Fundamental idea
1. Copy (all or selected) documents from old to new media
2. Remove old media from Archive Server
Motivation
Aging of media → data may volatilise
Aging of technology → compatible drives may not be available forever
Storage migration → migrate to storage system with "virtual
jukebox"
Expiration of data → after given retention period
Re-organisation → apply new features to old documents:
compression, encryption
Archive Server tool: volume migration

Enables migration on document component level
More powerful and flexible than migration on file or filesystem block
(“physical”) level

Volume Migration – Process
vmig_work
vmig_work
triggers doc.comp
doc.comp 11
Periodic
PeriodicADMS
ADMSjob
job doc.comp
migrate 33 10 Migration doc.comp 22
migrate 10 doc.comp
doc.comp 33
server
comp- ...
...
Tasks: ares
vmig_jobs updates
vmig_jobs 11
11
22 volume
volume 11 status Review
volume 2
volume 2 12
12 status
...
... 44 ds_job
ds_job ds_comp
ds_comp
creates 66
Enqueue doc.comp
doc.comp 11 doc.comp
doc.comp 11
proces-
ses doc.comp
doc.comp 22
creates doc.comp
doc.comp 33
reads 14
14 ... ...
... ...
reads
contents
Migrate
Migrate Check
Checkmigration
migration listing
status 77
utility
utility statusutility
utility 55
reads creates
99
11 uses Media
13
13 Media
copies write
writejob
job
reviews 88
15
15
removes
Administrator Old medium New medium

Volume migration is organized per medium (= “volume” — but the two sides of a UDO, WORM or DVD count
separately!). The whole migration process for a single medium is composed of the following stages:
Creation of migration jobs
1. The administrator starts the migration utility (in the Archive Server administration) and specifies a
selection of media and documents to be migrated.
2. The utility creates one “migration job” per selected medium (stored in the DS database).
Enqueuing document components for migration
3. The Migration Server is triggered by a periodic Archive Server job.
4. The Migration Server reads the migration jobs, i. e. volumes that are queued for migration.
5. It reads from the DS database which document components are stored on the selected volumes and
therefore are to be migrated.
6. It enqueues each found document component in the normal “writing queue” that is also used for
managing the writing process from the disk buffers to optical media.
Copying document components to new media
7. The media write job of the migration target pool is started and reads the “writing queue”.
8. It copies the document components from the source media to new target media.
9. It updates the database to reflect which components have been copied.
Updating status of migration jobs
10. The Migration Server is triggered the next time by the corresponding Archive Server job.
11. The Migration Server checks which document components have been copied in the meantime.
12. When all document components of a migration source medium are found to be copied to new media,
that medium’s migration job is marked as “finished”.
Finishing the migration
13. The administrator invokes the Check migration status utility in the administration client.
14. The utility reads the migration jobs and displays the status for each volume.
15. The administrator removes media whose migration is finished from the system (exports from DS
database and removes media from storage system).
16-4 710-97
Migration Server’s work
Migration Server
Service process controlled by spawner (volmig.exe) 33
10
10
Operation controlled by periodic job command Migrate_Volumes
Checks/updates status of previously begun volume migrations 11

11
12
12
Checks for enqueued components: already written to destination media?
Checks for overdue components (not written within a week)
Purges work items from finished volume migration jobs
44
Processes new/pending volume migration jobs 55
Gathers components from volumes according to administrator’s selection 66
Enqueues components for writing to destination pool

Stops enqueuing when given limit is reached
– Default: 10 GB per migration run
– Remaining components are deferred to next Migration Server invocation
Writes migration logfile to <OT logging>/migration/ for each medium
The items mentioned above reveal that the Migration Server’s tasks are more elaborate than the
previous page suggests; to be mentioned here are the check for overdue components and the
limited amount of data processed at one migration run.
Correspondingly, the Migration Server has two important configuration options:
• Max. amount of data to be enqueued per migration run (default: 10 GB)
• Max. period of time after which enqueued,
not-yet written components are considered overdue (default: 7 days)
These parameters can be maintained in the VMIG.setup within the Archive Server configuration

Additional considerations
Migration of all media types possible

Space requirements when migrating to DVD
– ISO image and directory tree must fit into ISO burn buffer
– No space in disk buffer required
Migration to WORM
– Direct copy without temporary buffer
Migration WORM → WORM
– Two drives required
Hard disk based pools (i. e. FS pool) as target
Bulk migration ISO images
Option to encrypt / compress data during migration
Migrating compressed data to a logical archive without compression
will not uncompress data
Retention settings can be applied during migration
Remote Migration for ISO and IXW as source possible
Job Manipulation options
If you want to learn more about Volume Migration options, see Technical Information on Volume
Migration in KC:
https://knowledge.opentext.com/knowledge/llisapi.dll/open/1140188069_686
Old OR3 structures used in early DS versions are not supported.
16-6 710-97
Chapter guide
Doing the migration

Involved steps
Additional features
Document migration


Preparation steps – Create Migrate Volumes Job
Schedule periodic job

for triggering Migration Server
Command Migrate_Volumes
Preferably schedule to run
during periods of low system workload,
e. g. during the night To
Tobe
bedone
doneonce
onceper
per
Archive Server
Archive Server

The job for running the Migrate_Volumes command is not present on an Archive Server by
default, i. e. you have to create it before you can start migration projects. To do so:
1. In the Archive Server Administration, tab Jobs, choose New Job from the Actions
menu.
2. Enter a name for the job. This name can be chosen freely, but should preferably be
meaningful, i.e. Migrate_Volumes.
3. Choose the job command Migrate_Volumes from the list, as illustrated above.
4. Schedule the job as desired. Normally, it is most reasonable to have the job run once a
night.
It might also be a good idea to concatenate this migration job and the write job of the migration
target pool; this way, both jobs can do their work without wasting any time, giving you more
flexibility to schedule other jobs (see also chapter Periodic Jobs).
For details about creating a media pool as the migration target, see chapter Configuring Logical
Archives. The only specialty in this situation is the application type Migration, as illustrated
above.
16-8 710-97
Preparation steps – Create Migration Target Pool
Create a new Storage Tier

i. e. named migration
Create migration target pool

In same logical archive To
Tobebedone
doneonce
onceper
per
as source media reside “migration project”,
“migration project”,
at
atleast
leastonce
onceper
per
Choose target media type (not HDSK!) logical archive
logical archive
Choose Storage Tier, i.e. migration
Schedule and configure write job properly

Since Archive Server ≥ 9.7.1, you need to create a Storage Tier before you can create second
pool for a Logical Archive (previous Archive versions used application types for this purpose).

Plan migration for selected volumes
Specify source volumes
Caution: Source volumes must not be

assigned to target pool!
Specify target
archive & pool
Optional document
component selection
by storage date
Optional Retention Settings
Optional Export after migration
! Make
Makesure
surethat
thatmedia
mediaplanned
plannedto
tobe
bemigrated
migratedare
areonline!
online!
In order to plan migration of certain storage media, invoke the Volmig Migrate Components
on Volume utility from the Utilities item in the Archive Server Administration. Specify the
following:
• Source volume: Names of the storage volumes to be migrated. Multiple volumes can be
selected by including regular expressions:
– Ranges in square brackets. Multiple ranges <from>-<to> and single values can be
concatenated with commas as separators.
This will mostly be used to select ranges of media sequence numbers.
Caution: Make sure you pad numbers with differently many digits with leading
zeroes to equal length! (Not: [1-123], but: [001-123])
– The wildcard character ‘*’.
Make sure you select volumes from a single logical archive only! This is mostly insured by
the logical archive name as part of the volume names, specified here literally (not by
wildcard).
• Target archive & pool that will contain the newly written media.
• Migrate only components that were archived …: You may optionally select document
components to be migrated according to their time of archiving. This is useful if, by the
opportunity of migration, you intend to get rid of expired documents on the source media.
• Do not migrate components … newer versions …: This is always reasonable because
newer component versions always supersede older versions; those older versions are
therefore never needed any longer.
The Migration Server will access the selected media for reading status information of the stored
documents during the document enqueuing stage already (see also next page); for this reason, it is
mandatory to have the media online (known to DS database and available in storage system) as
soon as their migration is planned the way described above.
Additional settings
– Retention Settings, i. e. no. of days
– Verification mode, i.e. none (see following slides for details)
– Additional arguments, i. e. –e for export after migration
16-10 710-97
Review migration progress of volumes
Output of ADMC’s Volume migration status utility:
Status Fin → Migration of this volume successfully finished;

volume can be exported from archive
Detailed enqueing log in <OT logging>/migration/<volname>.log

Includes listing of all enqueued components

To retrieve the migration status listing shown above, choose Volume Migration Status from
the Utilities menu in the Archive Server Administration. As the first step, selection options will
be displayed, offering you to restrict the view to new, in-work, and/or finished migration items.
Here, choosing no option at all is equivalent to choosing everything for display.
• Status New: A migration job for the volume has been created (using the Migrate
components on volume utility), but the Migration Server has not yet begun to enqueue
document components stored on it.
• Statuses In progress: The Migration Server has enqueued all components from the
source volume, but not all components are written to their destination media yet.
• Status Fin: All enqueued document components of the medium are already written to
destination media (i. e. are listed in table ds_comp). The Migration Server has therefore
purged the corresponding component entries from table vmig_work.
• Status Canceled: In Archive Server ≥ 9.6, it is possible to interrupt or cancel the migration
process.
• Status Error: Volume migration encountered a problem during the migration process.
You can check this tables in sqlplus, e. g.:

sqlplus ecr/ecr@ecr_<servername>;
select table_name from user_tables;
select * from vmig_jobs;
select * from vmig_work;

Pause Migration Job
Utility Pause Migration Job

vmclient pauseJob <jobID>
NEW, PREP, COPY PAUS
Utility Continue Migration Job

vmclient continueJob <jobID>
PAUS, ERR previous mode

16-12 710-97
After a migration project
When all “old” media are migrated:

Make migration target pool the default pool (optional)
Possibly, you may want to delete old (source) pool
Target pool will become Default

You may remove the Storage Tier
New documents are then added to former migration pool

on “modern” media


Chapter guide
Doing the migration

Involved steps
Additional features
Document migration

16-14 710-97
Verification after Migration (1)
Volume Migration can verify

Timestamps
Checksums
Compare content
BLOBs checked as one component

no individual check of contained components
Individual checksum types can be disabled

Verification mode adjustable until migration job has finished
Migration job remains in status WAIT until all components have been
verified

The following checksums are possible:

– CRC32
– CL_SIG (typ. SHA-1)
– SIG (message digest from timestamp)
– DIG2 (SHA-1)
– DIG3 (MD5, disabled per default)
– DIG4 (RipeMD160)
– DIG5 (SHA-256)
– DIG6 (SHA-512)

Verification after Migration can be

configured in
VMIG.Setup:
<archive_setup>/config/setup/
Archive Admin Client

16-16 710-97
Checks can be combined

Timestamp verification
Checksum verification
Binary comparison

More options are available on using the command line tool vmclient.

Bulk migration of ISO images (1)
Fast migration = Bulk migration

All kinds of ISO images can be migrated
CD, DVD
Centera
WORM
– If written by dsCD only!
– No finalized IXW media
HSM
Faster than classic migration

No document date filter
Volume name is retained

16-18 710-97
Simple backup medium

Cloned images are transparent to DS
Impossible to decide where to read data from
Impossible to perform verification on a document basis
Whole ISO image has self-contained checksum
– verified automatically
All document attributes remain unchanged


Fast Migration of ISO Volume
Source Volume
Target
Archive or Pool

16-20 710-97
Bulk migration of remote ISO volumes (1)
Fast Migration of remote ISO volume
DB connection
Source volume
Target archive/pool
Verification mode
Options


Bulk migration of remote ISO volumes (2)
Source and Target distinguishable

Verification supported on document basis
Change of archive/retention supported
Deleted documents don't reappear
"dumb" mode uses dsTools importCD

No change of archive/retention
Deleted documents will reappear

16-22 710-97
Run Migration per Pool
Optional parameter for job

migrate_volumes
-p <pool>
One instance of
migrate_volumes job per
pool possible
Higher priority for pool by
scheduling its
migrate_volumes job more
often
Jobs can not run in parallel

Exercise: Do media migration
Prepare media migration

Create migration job
Create destination media pool
Enqueue medium for migration

Check status
Run migration job

Check status again
Run destination pool’s write job

Check status again
Run migration job again

Check status

16-24 710-97
17 Export and Import of Storage
Media
Keeping your Archive Server clean of
outdated documents
Slide 1
Export and Import of Storage Media 17-1

Possible states of optical archive media
In device
Known to
Online (= readable)
storage database
Original volume …
… read/writable
Removed
… read-only from jukebox
Original volume offline A
Backup volume B
Empty Exported
Uninitialized
Bad volume
Export and Import of Storage Media • Slide 2

Serving as a continuation of chapter Handling Optical Archive Media, this chapter discusses the
media state transitions illustrated above:
A As soon as the retention period of all documents on a medium has passed, the medium and
its contents can be exported from the storage database; the Archive Server then “forgets”
about those documents.
B However, exporting a medium is not one-way. An exported medium can be re-imported into
the server again — or, as well, be imported into a different Archive Server which then
possesses the media contents. This is especially useful in situations where you want to
move all your stored contents to new server hardware.
The following pages present details about how to perform each of the mentioned transitions.
On command line:
C:\> dsTools export <volume name>
C:\>dsClient localhost dsadmin ""
-> volInfo [<volume name>]
-> delVolume <volume name>
-> end
C:\>cdadm delete <volume name>
C:\>sqlplus ecr/ecr@ecr_<servername>
-> select table_name from user_tables;
-> select * from ds_volid;
-> exit
17-2 710-97
Exporting a medium: when documents’ retention
period has passed (1)
Document administration data A
is removed (“exported”) from storage
database
Medium must be online in jukebox!
If medium unavailable (e. g. destroyed):
Use option Export from DB
For unfinalized IXW medias only:
Export WORM filesystem data
as well
→ See Administration Guide
This way, Archive Server forgets about
those documents
Documents are no longer
retrievable
Nevertheless: Do not
throw away exported media

In order to remove media containing expired documents from the Archive Server permanently,
invoke the Export Volume dialog of the Archive Server Administration as illustrated above. Set
the checkmarks in the dialog box as shown above and confirm with OK. A message window will
then appear, showing the progress of the database export procedure as well as possible error
messages.
Exporting an unfinalized IXW media from the Archive Server, removing its filesystem
administration data from STORM’s database is a separate action. For details, see the
Administration Guide, section Exporting non-finalized IXW volumes.
Notes:
• Media should be exported according to the point of time of last writing. This way, you make
sure that all documents stored on them really have expired.
• About the export options in the Export Volume(s) dialog (illustrated above):
Export from DB: Without this option (i. e. in the standard case), the export tool scans
the medium in question for documents to be exported, then it deletes from the DS
database all data about exactly the found documents. In case of inconsistencies
between database and medium, this prevents erroneous deletion of “wrong”
documents.
With this option enabled, the medium is not touched; instead, the information which
documents are to be exported is taken from the database itself. If the database and
the medium are consistent to each other, the result is the same in both cases.
Conclusion: Not using this option is the safer variant. Use it only in emergency
cases, i. e. if the medium is no longer accessible (lost or destroyed).
Export Volume Name: Using this option, the database “forgets” about the medium itself
along with the documents stored on it. This option should always be enabled
(otherwise re-importing the medium later would cause trouble).
• For the sake of data loss protection – unless required for legal reasons – never dispose of
any archiving volumes!

Exporting a medium: when documents’ retention
period has passed (2)
Identify Volume name(s) to be exported

1
Export Volumes 2

Check volumes in your archive pool to identify the correct volume(s) for export. You can copy the
volume name from the volume properties and paste it into the export command.
In Archive Server ≤ 9.6, this is can be done easier by right-clicking your volumes in the archive
pool.
17-4 710-97
Single-instance archiving (SIA)
A
and media export
Exporting old media may leave “dead” SIA references behind

Export media of SIA-enabled archives with dsTools
Standard Livelink Enterprise Archive Server command line tool
dsTools listRefs <volume_name>
– produces a list of volumes and components pointing to the volume
Exporting media with dsTools [options] export <volume_name>
– Default behaviour: Does not export a target component
if references are still pointing to it
– Option -f (“force”): Exports a target component
even if sources are pointing to it
– Options -v -V: Produces a list of volumes or components
pointing to the current volume
Source_2 Target_2
Target_1
Source_1

Since single-instance archiving introduces dependencies between documents that may be stored
on different storage media, tools dealing with export and import of documents must take this into
account.
The situation is special because a SIA reference to a document may be created long after the
document itself has been stored; the reference will then probably be stored on a newer medium
than the document. On the other hand, “old” media are normally exported in chronological order, i.
e. the medium containing the originally stored document would be exported before the reference
(on the newer medium) would vanish from the archive.
On this background, the administrator’s challenge is: How to avoid such dead references during
export of expired media?
This is possible using the Archive Server command line tool dsTools instead of the export facility
embedded in the Archive Server Administration. The dsTools features mentioned above enable
the administrator to handle SIA references across storage media reliably.
See next page for a description how to use dsTools for exporting media containing SIA targets
properly.

Steps for exporting a medium of
a SIA-enabled archive
1. Check whether SIA references point to this medium A
dsTools listRefs <volume_name>
If so:
2. Export medium, preserving referenced SIA target documents
dsTools export <volume_name>
3. Migrate medium to new media

Using the Volume Migration tool (→ chapter Media Migration)
Only the preserved SIA targets will be copied
4. Export medium again, forcing complete export

dsTools -f export <volume_name>
Keeping SIA targets is continued on the media created in step 3

Handling the export of media containing SIA targets involves the dsTools tool — introduced on
the previous page — as well as the media migration facility discussed in chapter Media Migration.
The step sequence described above utilized the fact that the media migration tool copies only
those documents to new media which are known to the DS database. Using dsTools to “forget”
all other documents in advance (step 2) leads to the behaviour desired here: Only those
documents are preserved on new media that are still referenced by SIA “sources”, which means
that they will possibly be requested for access in the future.
17-6 710-97
B
Importing a medium
Makes medium and its contents known to DS database again

No difference to before export
Usefulness:
Moving stored data to other server
Re-importing data that has been erroneously exported
Medium must be
in jukebox
For unusual situations, e. g.

moving documents
between logical archives

Media, once their contents has been exported from the storage database, can be re-imported
again (for example, if they have been exported erroneously). For this, right-click the medium in the
jukebox contents list in the Archive Server Administration — as illustrated above — and use the
appropriate Import ... Volume(s) item of the Utilities context menu.
For a normal medium import, the default options of the import dialog can be used.
The import … Volume(s) windows are GUI versions of the command line tool dsTools.
To look for additional arguments start dsTools on command line, then you will see all parameters.
-q speed up import by not determining component length from compression
header
-t <days> only import documents newer than <days> days, speeds up recovery from a
DB crash, where latest DB backup is less then <days> days old

Media Import & Index Reconstruction
reconstruction of index
in DS prevented
remembers previously
deleted media
deleted documents tracked
in table ds_deleted
remembers previously
deleted documents
import
media Archive DS
denied! Server database

DS database remembers documents that have been deleted before. This information is stored in
table ds_deleted. If you try to import media with the deleted documents, import of the deleted
documents will be prevented.
In older Archive Server versions up to 9.5, when importing media with documents that were
previously deleted, the documents would be in the system again.
17-8 710-97
Exercise: Export/ import a medium
Export a medium from the DS

database
Check the status of a sample
document stored on the medium
With dsClient
Trying to retrieve the document
Re-import the medium

Check the document’s status again


17-10 710-97
18 Consistency Checks for Storage
Media and Database
Detecting problems between storage
media and storage database
Slide 1
Consistency Checks for Storage Media and Database 18-1

Consistency checks: overview
Check database against volume

Check volume against database
Check only volume
Check document
Compare backup IXW medias
Consistency Checks for Storage Media and Database • Slide 2

18-2 710-97
Check database against volume
Are all documents known to database really stored on volume?
Detects documents missing on storage medium
Usefulness
After restoring an original WORM from the backup
When suspecting damage of a storage medium
Medium to be checked must be online
Possible reactions on inconsistency
Report error, but do not try to repair (check only)
Try to recover missing file from other storage volume
(e. g. from disk buffer to IXW media)
– Media to copy from must be online
Delete “dead” reference from database (“export component”)
→ May lead to document loss! Get help from Open Text Support if in doubt.
“Everything stored correctly

Database on this medium?”
abc12…
def34…
ghi56…

The “export component” repair option is somewhat dangerous: Depending on the exact type of
inconsistency, you may lose references to documents that are still stored somewhere in the
archive. But even if there is no more instance of the document within the archive, recovering the
document from external sources (if that is applicable) may require the reference information in the
database to still exist.
Therefore: Use this repair option only if you are sure that you do not need the missing documents
any longer! If in doubt, rather contact Open Text Support for help.

Using consistency check tools
Copy volume name

from archive pool

18-4 710-97
Check volume against database (1)
Are all documents stored on volume really known to database?

Detects lost document references in database
Usefulness
Database recovery
When suspecting problems with the database contents
Medium to be checked against must be online

Recreate missing reference in database (“import document”)
“All documents stored on this medium

also referenced by the database?”
Database
abc12…
def34…
ghi56…


Check volume against database (2)
Copy volume name

from archive pool

18-6 710-97
Check only volume
Is document structure on volume consistent?

Detects corrupted documents on medium
Usefulness
When suspecting any kind of problem with a storage medium
Medium to be checked must be online

Error reporting only — no repair options available
“All documents on this medium

have consistent structure?”


Check document
Is document stored correctly on media, as known by database?
Detects “lost” storage locations of a single document
Usefulness
Analyzing trouble accessing a specific document
Media carrying components of the document must be online
Repair inconsistency:
– If missing file is still stored on another medium: recover it from there
– Otherwise: Delete the “dead” reference from database
→ May lead to document loss! Get help from Open Text Support if in doubt.
“This document stored correctly (Disk buffer)

on all referenced media?”
Database
abc12…

The repair option of this check utility is somewhat dangerous: If a document component is missing
on the referenced storage volume and it is not known to be stored on any other volume, the utility
would delete this “dead” reference to the missing component. Depending on the exact type of
inconsistency, this may cause the database to “forget” document components that are still stored
somewhere in the archive. But even if there is no more instance of a missing component within the
archive, recovering the component from external sources (if that is applicable) may require the
reference information in the database to still exist.
Therefore: Use the repair option only if you are sure that you do not need the missing document
components any longer! If in doubt, rather contact Open Text Support for help.
18-8 710-97
Compare backup IXW medias
Are WORM backups consistent with the original?

Detects corrupt IXW backups
Usefulness
When suspecting corruption of WORM backups
Original and backup IXW medias must be online

Error reporting only — no repair options available
“Are backup(s) consistent

to this original IXW media?”
Original
Backup(s)


Exercise: Check and repair consistency between
medium and database
Check IXW or ISO medias against

database
Without repairing (reporting only)
Examine results
If necessary, run check again with

repair option
Examine results
Run check again

Examine results; no errors should
occur now

18-10 710-97
19 Expanded Archive Server
Installations
Improving data safety and performance by
increasing redundancy
Slide 1
Expanded Archive Server Installations 19-1

Chapter overview
Possible major configurations:

Archive Server — basic configuration
Optical media as originals plus backups in same jukebox (= standard)
Backup copies in a separate jukebox
RemoteStandby
Remotely replicated archives and buffers
HotStandby
Automatic failover system
CacheServer
Separate server minimizing network load for read & write access
Expanded Archive Server Installations • Slide 2

19-2 710-97
Local Backup of Media
Backup of media by Archive Server

Archive Server
Backup in same storage device or
another device
Volume B Volume A Copies of ISO images are treated as
one logical volume
Load balancing during read
Read failover if one medium not
Storage available
Copy of A Devices Copy of B
Logical Volume
Identical copies of an ISO image


Single Archive Server with separate backup
jukebox
Fire protection
wall possible
Second
SCSI
jukebox
Archive Server
Jukebox
RAID

An Archive Server with one jukebox and backup copies of the media is the standard minimum
configuration. RAID 1 or 5 is used for the Archive Server’s hard disk space.
This scenario assures that all data archived on optical disks is stored on duplicate partitions. As
the duplicate partitions are produced in the same physical jukebox where the originals reside, the
duplicates should be removed to a safe place for maximum security.
To improve protection against hardware failure and natural disaster you can create backup copies
in a separate jukebox.
19-4 710-97
RemoteStandby
RemoteStandby
SCSI SCSI
Replication
WAN
RemoteStandby
Archive Server
Periodic data replication
SCSI
On storage media level
Configurable per logical archive / disk buffer
Local read access
Minimizes network load
Load distribution on involved servers
“Full read access” in case of fail over
With certain scenario restrictions

This configuration supports remote replication. With it you can replicate archives and pools. In the
RemoteStandby scenario, a fully functional, remote Archive Server is capable of replicating the
archived data of an original Archive Server over significantly great distances by virtue of a WAN
connection. The configuration is implemented from the RemoteStandby server (a maximum of
three RemoteStandby servers can be configured). The RemoteStandby server replicates
asynchronously the archives and hard disk buffers of the desired original server. The replication
interval is specified on the RemoteStandby server. It is performed as a "synchronize" function from
the RemoteStandby.
A RemoteStandby server provides read-access to its replicated archives. Should anything happen
to the original server, all archived documents present at the time of the last “replicate
synchronization” can be retrieved from the RemoteStandby server.
The configuration “original archive — RemoteStandby archive” may be a reciprocal one. An
Archive Server may be an original server as well as a RemoteStandby server for a second original
server. This configuration provides two major advantages. First, you exploit the hardware available
to you by giving it double-duty. Second, access to a document retrieved from a local replicate
archive is much faster than retrieving the identical document from the original server thousands of
miles away.

Architecture of Remote Standby (1)
Logical archives are replicated:

Disk buffers and media
Storage Systems Remote

Standby Server
Storage Systems Original Archive Server
Note
Fully replicated archive server No synchronous write!
Performance balancing Difference between original and backup possible
Full Read Access in case of failover (DS not
One RSB: same MEDIA are required, but not
available)
same devices
Exception:
HD-WO to DVD, WORM

19-6 710-97
Architecture of Remote Standby (2)
A1 Remote Standby Server for

A1 A2
A2 2 local sites
Archive Server A Logical Archives

A1‘ A1‘ A2‘
A2‘ B1‘ B2‘
B1‘
B2‘
Archive Server C Logical Archives
B1 B1 B2
B2
Archive Server B Logical Archives


Switch over to remote standby ...
User waits for response -

Wait up to 120 seconds before switch over
Up to 3 servers can be configured
Server priorities can be defined
Remote Standby Server

The next three slides, describe the process of retrieving a document, in case of a failure of a piece
of hardware.
We assume that there are three Archive Servers in the company. The clients connect by default to
Server one!
Server Priorities
• In a remote standby configuration, documents can be requested from both the original
server and the remote standby servers. You use this command to define the sequence in
which the servers are accessed for each replicated archive. It is usually quickest and most
efficient to access the closest server.
• It is not important on which server you specify the server access sequence. The setting
affects all the known servers.
19-8 710-97
Scenarios for Remote Standby Server
Only read access – archiving not possible

Scanned documents can be buffered in local pipelines
for a while
Supported by LES (Enterprise Server) API, CacheServer, Archive Viewer,
Email Archiving
Useful scenarios
Early & Late archiving with barcode
COLD
DocuLink
Not useful / not available:

SAP Data Archiving


HotStandby
Fire protection wall
Archive Server HotStandby server

RAID 1
active dormant
Fibre channel
Backup
Original jukebox
jukebox
Automatic failover system

Symmetric cluster via fiber optic connection
Same topology for all platforms, Windows and Unix

A HotStandby server is the key component for this configuration. The Archive Server high
availability system guarantees against loss of time as well as against loss of data. This scenario
provides a fully functional second Archive Server capable of taking over operations automatically if
the original sever should fail for any reason. This HotStandby server monitors the original server; in
the case of system failure, the HotStandby takes over automatically. In Archive Server, this is
referred to as an automatic failover system.
In the automatic failover configuration, two Archive Servers access the same RAID-protected hard
disk partitions, although not at the same time. The HotStandby server is connected to one or more
jukeboxes containing backups of the original archived documents. This is implemented by backup
jobs that run regularly between the two. The hard disk buffer and pools are shared and they are
protected with RAID 1.
If the original server should fail, the HotStandby starts automatically, working with the data stored
on the commonly accessed hard disk partitions. By means of a fire protection wall the automatic
fail over scenario can protect against the threat of fire.
Distances up to several kilometers between the cluster nodes are possible.
19-10 710-97
Hot Standby Server with two hubs
Server1: active Shared disk array Server2: dormant
SCSI / fiber channel SCSI / fiber channel
FC FC
FC hub
FC/SCSI FC/SCSI
bridge bridge
Jukebox Jukebox


Hot Standby and Remote Standby Server
Archive Server Cluster
A1
B1 Replicate Disk Buffer
Remote Standby Server
Archive Server Shared disk system Archive Server
active dormant
A1‘ A1‘
B1‘ B1‘
Storage Network
Devices
A1 B1
B1‘ A1‘ Archive Server RSB Logical Archives
Replicate Partitions
Crosswise backup of media/partitions

19-12 710-97
Features of a Hot Standby Server
Full system availability after approx. 5 minutes

Clients who didn’t access the archive server during downtime will not
notice the server swap
Read / Write access in case of failover
No mirroring of storage systems
Recommended for critical scenarios

Availability > 99 %
High access rates
Workflow scenarios


Cache Server
Archive Server CacheServer

First read access
SCSI
First read access
WAN Su
bs
e qu
en
tr
ea
da
Acts as a proxy server cc
es
Caches transferred documents on hard disk s
No optical storage equipment
No storage database
Reduces WAN load for read & write requests

Write-through cache for archiving actions
Requires HTTP communication for archiving Local
area
m Archive Servers : n CacheServers possible network
Not suitable for data recovery purposes

The CacheServer caches every document that someone has had a look at in your local network.
This avoids the WAN stroke as a performance bottleneck for further read accesses.
When a document is archived, the CacheServer transmits the document to the connected Archive
Server immediately (“write-through”) and keeps a copy in its local cache.
In addition to enhancing read request performance, using the write-back cache feature can
improve also WAN load for write requests. Writing to Archive Server is delayed and can be
performed i.e. during night when less load is expected.
19-14 710-97
Cache Server Scenario
LAN
WAN
CacheServer Logical Archive: US
Central Archive Servers & Storage Devices

Logical Archives: EU, Japan, US
LAN
WAN
LAN
CacheServer Logical Archive: Japan
Europe


Cache Server
Decentralized data storage (copy of stored data)

Separate hardware
Just big file server
No storage devices needed
No database needed
Write through cache or scheduled write-back cache
Read once
Document validity is checked on a new read request
Documents are stored in hard disk cache (FIFO or LRU)
Transparent for clients
Supported for Windows and Java Viewer
Project specific perfecting possible

Some specific Cache Server aspects:

– Timestamp verification is done by the archive server.
– Cache server cannot be used in a stand alone modus when archive server cannot be
reached.
– If document is out of date, only the component (not document) is sent anew.
– Caches server supports FIFO (first in first out) and LRU (last recently used) caching
strategy.
19-16 710-97
Input Scenario and Local Cache Server
Local sites: Document
Document
input input
Scanning scanning
scanning
Retrieval mainly
of local documents
Document
Pipeline Documents are fetched from local Document
HTTP CacheServer Pipeline
HTTP
No central document access
necessary for reading
Cache (only DocumentInfo) Cache
Server
Server
Central access to index write back/
write back/
data through
through
Central Archive Server with Index

Database
IT infrastructure
optical devices
administration
backup


Remote Standby Server versus
Cache Server
Remote Standby Server Cache Server

Security & Availability Volatile document storage
Copy of entire logical archive Documents can be swapped out
guaranteed (FIFO or LRU)
Additional storage devices for Suited for many small local sites
remote-standby server necessary (< 100 users)
High (read only) access rates No storage devices in local site /
no administration / no database
Temporary differences between
original and backup possible Less net traffic when using local
scanning with subsequent read access
Two replicates possible
Less performance during write
Less investments

19-18 710-97
Summary
Protection against …
Target
data loss due to … Load
Con- system distribution
media natural downtime
figuration failure
fire
disaster
Single Archive
Server with single X
jukebox
Second jukebox X X
(X)
RemoteStandby X X X Read functionality X
only
HotStandby X X X
CacheServer X

This overview shows the main advantages of the different solutions. No solution alone can protect
you against every potential problem. Each Archive Server customer has to choose an optimal
solution according to risks, cost, and main concerns.

19-20 710-97
20 Remote Standby Configuration
and Operating
Steps for remote storage replication
Slide 1
Remote Standby Configuration and Operating 20-1

Chapter guide
Introduction
Configuring replication
Servers
Logical archives
Disk buffers
WORM pools
ISO pools
Executing and reviewing the replication
Replication with Storage Systems - Examples
Remote Standby Configuration and Operating • Slide 2

20-2 710-97
Basic concept and benefits
Remote Standby
Replication
WAN RAID 1 Remote Standby

Archive Server
Periodic data replication

On storage media level
Configurable per logical archive / disk buffer
Local read access
Minimizes network load
Load distribution on involved servers
“Full read access” in case of fail over
With certain scenario restrictions

This configuration supports remote replication. With it you can replicate archives and pools. In the
RemoteStandby scenario, a fully functional, remote Archive Server is capable of replicating the
archived data of an original Archive Server over significantly great distances by virtue of a WAN
connection. The configuration is implemented from the RemoteStandby server (a maximum of
three RemoteStandby servers can be configured). The RemoteStandby server replicates
asynchronously the archives and hard disk buffers of the desired original server. The replication
interval is specified on the RemoteStandby server. It is performed as a "synchronize" function from
the RemoteStandby.
A RemoteStandby server provides read-access to its replicated archives. Should anything happen
to the original server, all archived documents present at the time of the last “replicate
synchronization” can be retrieved from the RemoteStandby server.
The configuration “original archive — RemoteStandby archive” may be a reciprocal one. An
Archive Server may be an original server as well as a RemoteStandby server for a second original
server. This configuration provides two major advantages. First, you exploit the hardware available
to you by giving it double-duty. Second, access to a document retrieved from a local replicate
archive is much faster than retrieving the identical document from the original server thousands of
miles away.

Proposal: central backup for multiple servers
Central
CentralRemote
RemoteStandby
Standby
SCSI
Replication
LAN / fast WAN

Replication
Local
LocalArchive
ArchiveServer
Server11 Replication
Local
LocalArchive
ArchiveServer
Server22
SCSI Local
LocalArchive
ArchiveServer
Servernn
SCSI
LAN / fast WAN
SCSI
LAN / fast WAN
LAN / fast WAN

One style of RemoteStandby operation is the one illustrated above: Having multiple original
servers, possibly geographically distributed, plus one central RemoteStandby server backing up all
of them.
20-4 710-97
How replication is performed
“Original” server Remote Standby server

Disk
Disk Disk
Disk
buffer
buffer Vol. 1 Vol. 1 buffer
buffer
Replicates new documents
Replication
Deletes purged documents
Vol. 2 Vol. 2
Original data copied

from disk buffer
job
to optical media
Log.
Log. IXW IXW Log.
Log.
IXW IXW
archive
archive pool pool archive
archive
pool Replicates new documents pool
Log.
Log. ISO ISO Log.
Log.
ISO ISO
archive
archive pool pool archive
archive
pool Replicates whole media pool

For RepmoteStandby replication, the following distinction must be considered:

• It is configured on the level of disk buffers and logical archives.
• It is performed on the level of storage volumes.
In addition to setting up the replication configuration for disk buffers and logical archives, the server
administrator or operator has to perform the following steps:
• For each replicated disk buffer, replicates of all assigned original buffer volumes (i. e. hard
disk partitions) must be provided and initialized on the RemoteStandby server.
• For all original IXW medias used by replicated archives, replicate IXW medias must be
provided and initialized on the RemoteStandby server (this task may be automated). This is
an ongoing task since new IXW medias will be allocated by the original server regularly.
• ISO media, however, do not need to be initialized explicitly on the RemoteStandby server; it
is sufficient to provide enough blank media there. The replication job will take an arbitrary
blank medium and fill it whenever a new medium has been written on the original server.
The remaining media operation tasks — labelling, storing backups away, setting offline and online
as needed — are the same for replicates as for media on the original server; see chapter Media
Operating for more information.

Chapter guide
Introduction
Servers
Logical archives
Disk buffers
WORM pools
ISO pools

20-6 710-97
Make original and Remote Standby servers known
to each other
On original server: On Remote Standby server:
Remote Standby
server
Original
server

Before replication of logical archives and disk buffers can be configured, both involved Archive
Server must be made known to each other — as illustrated above, in the Archive Server
Administration.
Making the Remote Standby server known to the original server, make sure to enable the Allow
replication option — otherwise the original server will deny sharing its data with the Remote
Standby server.
Port, Secure port, Context path

Specifies the port, the secure port and the context path, that enables the archive server to create
URLs of a designated Remote Standby Server.
Structure of the URLs:
http://<host>:<port><context>?...
https://<host>:<secure port><context>?...
Example:
host = vmlas
port = 8080
secure port = 8090
context = /archive
http:// vmlas:8080/archive?...
https:// vmlas:8090/archive?...

Replicate External Archives
Original Archives : Logical archives on local archive server

External Archives : Logical archives on known archive servers
Replicated Archives : External archives replicated on local archive server

As soon as original and Remote Standby servers know each other (see previous page),
configuring the replication of a logical archive is fairly easy:
1. Within the Archive Server Administration, connect to the Remote Standby server.
2. Go to External Archives, navigate to the desired logical archive on the original server.
3. Right-click the archive, choose Replicate from the context menu.
Now, the replicated archive will be found under Replicated Archives.
20-8 710-97
Replicate Diskbuffer
Replicate should have different name

(to avoid naming conflicts)
Condition: Capacity of replicate must be

at least equal to original

If a hard disk partition replicate is marked as “missing” on the Remote Standby server, a suitable
hard disk partition has to be provided for that purpose. Firstly, create such a partition on operating
system level. Make sure its capacity is at least the same as the original partition, otherwise not all
data held in the original can be replicated later!

Replicate WORM pool
Condition: Replicate and original must match

in block size and capacity

• For each storage medium assigned to the original archive or disk buffer, you see the state
of its replicate. The most important information here is whether a replicate already exists or
not. If a replicate is missing, the administrator has to provide an appropriate medium for this
purpose; the exact way depends on the type of medium:
– Missing IXW volume have to be initialized explicitly before replication can be carried
out (i.e. using Auto initialization).
20-10 710-97
Replicate ISO pool

• For each storage medium assigned to the original archive or disk buffer, you see the state
of its replicate. The most important information here is whether a replicate already exists or
not. If a replicate is missing, the administrator has to provide an appropriate medium for this
purpose; the exact way depends on the type of medium:
– Missing ISO volume do not need to be initialized; it is sufficient to supply empty
media in the jukebox of the Remote Standby server. ISO media must have at least
the same capacity as the original media.

Chapter guide
Introduction
Servers
Logical archives
Disk buffers
WORM pools
ISO pools

20-12 710-97
The replication job
Schedule the job to run, e. g., once a day

Preferably let it run in periods of low system workload
E. g. during the night
Consider impact on network load during replication

Especially when replicating DVDs
Check for success or failure regularly

The replication job named Synchronize_Replicates is a predefined job on every Archive Server. It
must be executed on the Remote Standby server to perform the replication.
For successful replication, it is crucial to review the results of this job regularly for either success or
failure. This is done the same way as for all periodic jobs: In the Jobs tab of the Archive Server
Administration (shown above), right-click the jobs list and choose Protocol from the pop-up
menu. Then examine the displayed list of protocol items for job terminations marked with ERROR
or ABORT. If such an error item is present, right-click it and select Messages from the pop-up
menu to examine the logging output of the selected job invocation.

Replicated Volumes

20-14 710-97
Exercise: Configure and perform RemoteStandby
replication
Configure remote replication for a

logical archive
Cooperate with your classroom
neighbor: One has the original, one has
the Remote Standby server
Configure replication for a disk buffer

Supply media replicates where
necessary
Execute replication job
Examine result


Chapter guide
Introduction
Servers
Logical archives
Disk buffers
WORM pools
ISO pools

20-16 710-97
EMC Centera: ISO Images - Remote standby
Original Replication
Centera
Archive Server
Centera Archive Server
Logical archives are

replicated:
Optical
Archive Server
Replication either on
Centera or Optical

Replication to either Centera Centera or Centera Optical.

Replication by Archive Server only

EMC Centera: Single file - Remote standby
Original Replication
Centera Centera

Disk buffers and content

Opticals
Single file replication only Centera Centera

20-18 710-97
HDS DRU / HP XP: ISO – Remote Standby
HDS DRU
HP XP HDS DRU
Archive Server Archive Server HP XP


ISO images are replicated
ISO images can be stored on RSB on other media with pool type
Write-at-once (ISO)

HDS DRU / HP XP – LUN Security XP Extension

IBM DR550: single file & ISO –
Remote standby
DR550 Archive Server
Single documents & ISO images are
replicated
ISO images can be stored on RSB on
other media with pool type
Write-at-once (ISO)
Logical archives
WAN are replicated:
- Disk buffers
- media
DR550 Archive Server

20-20 710-97
NetApp Filer: single file & ISO –
Remote standby
Local System
Archive Server
with filer as Single documents & ISO images are
hard disk replicated
ISO images can be stored on RSB on
other media with pool type
Write-at-once (ISO)
Archive Server
WAN
replication
Remote Standby System
Archive server
with filer as
hard disk


20-22 710-97
21 Setting up an Administrator
Workstation
Prerequisites and tools
Slide 1
Setting up an Administrator Workstation 21-1

Chapter overview
Admin workstation requirements

Installing the Archive Server administration tools
Setting up an Administrator Workstation • Slide 2

21-2 710-97
Requirements for an administrator’s workstation
Graphical Archive Server administration client

Only on Windows platform!
Requires Microsoft MMC
Remote access to Archive Server

At least: File access
Admin client
– For viewing logfiles and configuration
Good: Shell access (telnet, ssh, …)
– For using command line tools
Ideal: Access to graphical console or screen
– Windows: Remote Desktop or 3rd-party tools
– Unix: X server
– Archive Server admin tools may be used on the Archive Server,
no installation on administrator workstation necessary

Unlike the previous Java based administration client (≤9.6.1), the current administration client
requires MMC and runs only on Windows platforms.
The graphical administration tool should be installed on the computer the Archive Server
administrator uses. This makes it possible to administer the Archive Server remotely.
However, if the admin workstation has graphical remote access to the Archive Server, you may
prefer to use the administration tools on the Archive Server directly; in this case, you can omit
installing the admin tools on your own workstation computer.

Installing the graphical administration tools
Installing on Archive Server or stand-alone client:

Install from Archive Server Installation CD
Setup Administration Client and other requested components
(i. e. DocumentPipeline Info)
Never mix components from server/client CDs with each other!

Generally, components of the Archive Server and the clients (Viewer & Scan clients) should never
be mixed on one machine.
Therefore, never install client components on the Archive Server.
21-4 710-97
Release dependency
Generally, Admin client release ≥ Archive Server release
Important for administering Archive Server with different releases
Use old Java based client for Archive Server ≤ 9.6.1 !
– Both admin clients can coexist on one machine
Installation on Archive Server

Always recommended where possible (Windows platform)
If missing: Can be post-installed without problems
– Precondition: Installed Archive Server and admin tools must have the same version


21-6 710-97
22 Periodic Jobs
Organizing recurring tasks on the Archive
Server
Slide 1
Periodic Jobs 22-1

Chapter overview
Tasks for jobs

Rules for running jobs simultaneously
Maintaining jobs in the administration client
Periodic Jobs • Slide 2

22-2 710-97
Tasks for jobs: synopsis (1)
Typical Resource-
Task Standard job name
schedule critical?
Related to media pools / disk buffers
Write data from disk buffer — ISO pool: daily Yes
to media IXW pool: hourly
Purge disk buffer — Daily Yes
Compress documents Compress_<arch>_<pool> Daily Yes

on hard disk pools
“Global”, document storage-related

Synchronize backup WORMs Local_Backup Daily Yes
with originals
Replicate data Synchronize_Replicates Daily Yes

RemoteStandby scenario
Start media migration — Daily Yes

This and the following page give a complete list of tasks that are normally done as jobs on the
Archive Server . (It is possible, however, to implement jobs for further administrative tasks, but this
is beyond Archive Server standard; the topic is discussed in the course 715 Archive Server
Advanced Admin)
Archive Server jobs are created and set up at different points of time:
• All jobs related to media pools / disk buffers are created (and also deleted) along with the
pool/buffer they are linked to; there is no need to self-define jobs for these purposes.
• Some jobs fulfilling “global” administrative tasks (i. e. not related to specific configuration
objects, such as pools and buffers) are already part of the initial Archive Server setup; this
applies to all above-mentioned jobs with a given standard job name.
• Some other “global” jobs are not set up at server installation time; you have to create them
yourself once you need their functionality. Concerning the list of jobs given above, this
applies to the “start media migration” task.
The typical schedule entries in the table above are meant as very general suggestions, valid only
unless special preconditions apply. The administrator is responsible to deviate from these rules of
thumb wherever necessary. Example: If the average amount of stored data received daily into a
specific ISO media archive exceeds the capacity of one ISO media, the ISO write job has to be
scheduled to run more than once a day — otherwise documents would continuously queue up in
the disk buffer.
The resource-critical column in the table above indicates which jobs have to scheduled with special
care: They allocate/consume certain resources (like media drives, database activity) to fulfill their
tasks, thus they should be scheduled in a cooperative way so that they do not lock out each other.
(More information is given later in this chapter.)
Periodic Jobs 22-3

Tasks for jobs: synopsis (2)
Typical Resource-
Task Standard job name
schedule critical?
“Global”, server-related
Update information about related SYS_REFRESH_ARCHIVE Daily No
(“known”) Archive Server
STORM files backup Save_Storm_Files Daily Yes
Reorganize STORM statistics Compress_Storm_Statistics Daily No
Reorganize accounting data Organize_Accounting_Data Daily No
Remove old job protocol entries SYS_CLEANUP_PROTOCOL Weekly No
Remove expired ADMC alerts SYS_EXPIRE_ALERTS Weekly No
Cleanup old Admin Audit Entries SYS_CLEANUP_ADMAUDIT Weekly Yes
Application-specific (examples)
Enqueue documents — Daily Yes
for batch import
Create page index for new — Daily Yes
SAP print lists

All jobs mentioned above under “global, server-related” are already part of the initial Archive
Server setup. The task remaining for the administrator is to schedule them appropriately as part of
the overall job scheduling concept.
See the previous page about the meaning of the typical schedule and resource-critical columns.
Audit Trails are available with Archive Server ≥ 9.6. Old administrative audit entries need to be
cleaned-up regularly. See chapter on Configuring Audit Trails for details.
22-4 710-97
Running several jobs simultaneously
Generally, multiple jobs can be executed at the same time

Schedule jobs so that they do not interfere with each other
Make sure enough resources are available for parallel execution
Coordinate jobs and periodic server downtimes (e.g. for offline backups)
Important bottlenecks:
Simultaneous ISO media writing
– Burn buffer large enough for keeping multiple ISO images?
– Enough writer drives available?
– Enough bandwidth on SCSI connection to writer drives to avoid buffer under run?
Simultaneous IXW media writing for several pools
– Enough drives available, also for simultaneous reading from other IXW medias?
General
– Enough CPU capacity, especially for jobs causing heavy database activity
(writing ISO media, purging disk buffers)?
Specifically, do not run simultaneously:

IXW media write jobs ↔ local backup job↔ save STORM files job
Local backup job ↔ disk buffer purge jobs (≥5.5: use job concatenation instead)
Further
Furtherreading
readingin
inKC
KC

Find the mentioned ESC article, entitled Scheduling jobs in Archive Administration, as:
If gives further information about the resource consumption of different types of jobs as well as
“best practice” examples for different scheduling concepts.
Periodic Jobs 22-5

Scheduling automatic daily jobs: Example
12 AM
Offline database backup

(controlled externally)
6 AM
Copy documents to WORM — A1

Copy documents to WORM — A2
12 PM Business hours
6 PM
Backup WORMs
Purge disk buffer
12 AM

In the illustration above, the Archive Server configuration comprises two logical archives: A1 and
A2.
The shown job schedule is characterized by the following considerations:
• During business hours — i. e. when new documents are expected to arrive on the Archive
Server — the Write_WORM jobs for the two IXW media pools run very frequently (e. g.,
each half hour) in order to store documents securely on IXW medias as soon as possible.
• The two other main tasks to be executed while the Archive Server is running, backing up
WORM data and purging the disk buffer, are arranged in a way that they do not interfere
with each other and with the IXW media write processes.
• The offline database backup must also be done while no other jobs are scheduled because
all Archive Server processes have to be shut down for this.
• Some other scheduled jobs, like refreshing configuration information about other Archive
Server and cleaning up expired job protocol entries, can be done concurrently to other jobs
without any problems.
However, the above scheme is just an example. Every Archive Server administrator is responsible
to find a solution that suits the individual situation at his own company.
Moreover, the job schedule and coordination have to be checked and possibly changed whenever
the Archive Server configuration is changed. For example, when a new logical archive with ISO
pool is introduced, another Write_CD job — which may take between one and two hours execution
time, depending on the speed of the ISO media writer drive — must be integrated into the existing
schedule.
22-6 710-97
Jobs administration
Job is
currently
being
executed
Job is
diabled
Job
schedule
“Edit” to
view
details
The Jobs property sheet of the Archive Server Administration shows the list of all defined jobs on
the Archive Server . The table yields the following information:
Icon: If the job icon is marked with a red "stop" icon, the job is currently disabled, i. e. ignored
by the scheduler.
The column may also display a further icon if the job is currently being executed, queued to
run at the next possible time, or stopping after an explicit stop command.
Name of the job.
Instances: Indicate that the job is running.
Command to be executed as a job. (It is not normally useful to edit this.)
Month, Day, Hour, etc.: The job’s schedule, if specified. A job may also configured to run
immediately after a certain other job has finished; this is displayed in the Job dependencies
list of the dialog.
Right-clicking the jobs list opens the pop-up menu shown above, offering functions for job
configuration and operating:
Stop interrupts a currently running job. Not all jobs allow this; e. g. ISO write jobs cannot be
interrupted.
Enable or disable a job. When disabled, the job will no longer be executed by the scheduler;
this may be useful for certain troubleshooting situations.
Edit the job’s command name, arguments, and — most important for configuration
maintenance — the job schedule.
Delete a job from the list. (This is not normally needed. If you want a job to no longer be
executed, rather disable it; see below.)
Periodic Jobs 22-7

Disable a Job
All jobs in the Job Administration

can be disabled
Scheduling will not trigger the job
Examples
Job is triggered by scripts instead
Redundant jobs not needed in scenario
Temporarily disable a job for a certain period
– Can be enabled at a later time

Administrators who are using their own scripts to trigger certain jobs need to be aware of the
regular job scheduling in the Job Administration. Disablling jobs can prevent collision with scripts
running the specific tasks.
Disabled jobs can be enabled again anytime.
22-8 710-97
Edit a job (1): scheduling
Command, arguments:
Do not alter for “standard” jobs
Invoke job by time
Multiple selection
of time values possible
Shortest interval: 1 minute

Choosing Edit in the context menu of the Archive Server Administration’s Jobs page opens the
Edit Job dialog of the selected job, as illustrated above.
The job properties Command and Arguments should not normally be edited since their default
values are always appropriate. Exceptions include:
• Adding option -b to the arguments of a disk buffer purge job makes the job purge
documents only after they have been saved on backup IXW media; see chapter Disk Buffer
Configuration.
• Application-specific jobs — mainly those starting batch import of documents — may honor
certain arguments (project-dependent).
Periodic Jobs 22-9

Edit a job (2): scheduling
“Time Limit”:
If job is being executed at specified
point of time, it will be interrupted
(“Emergency break”)
Some jobs will refuse to stop
Does not prevent scheduled start after
given time!

The job time limit can be used to make sure that certain jobs are finished at a defined point of time
during a day. For example, you can force a disk buffer purge job to terminate in time before the
database is shut down for an offline backup.
Note that most, but not all types of jobs honor this time-driven interruption: All activities dealing
with burning ISO media (DVD, WORM write jobs, local backup job — if applied to ISO pools) will
simply keep running even if they receive an interrupt request.
22-10 710-97
Edit a job (3): conditional invocation
Invoke job upon certain event
On AdministrationServer
startup (“autostart” spirit)
Triggered by finishing of
another job
→ job concatenation
– Optional condition:
specific return code of
previous job
(= successful exit?)
“Time Frame”:
Job will be invoked only during
given period
– E. g. only during the
night
Running job will not be inter-
rupted on exceeding the period!
Example concatenation:
1. Backup job for IXW medias
2. Purge disk buffer job

Job concatenation eases the coordination of resource-critical jobs. By simply chaining certain jobs
together, you can be sure that the second one never starts before the first one has finished.
Examples for reasonable job concatenations include:
• All ISO write jobs one after the other
• All IXW write jobs one after the other
• Local backup job, then disk buffer purge job(s)
Periodic Jobs 22-11

Additional recurring tasks
not executable as jobs
Various Archive Server backup tasks

Disk buffer / hard disk pools
Database
…
Exception: STORM files online backup
Archive database log files backup (Oracle)

The tasks mentioned above are indeed tasks to be performed regularly, but they cannot be
accomplished by the Archive Server’s built-in scheduler. (The scheduler needs a running database
for operation and therefore cannot invoke an offline database backup.) However, they are
mentioned here because they must be coordinated with the other system jobs — for example, an
offline database backup requires all Archive Server processes to be stopped; no other periodic
jobs can be executed during this downtime at all.
22-12 710-97
Exercise: Schedule jobs appropriately
Examine job scheduling on your

classroom server
Are jobs scheduled reasonably and
cooperatively?
Improve scheduling where necessary

Make use of job concatenation where
appropriate

Periodic Jobs 22-13

22-14 710-97
23 Configuring Audit Trails
Slide 1
Configuring Audit Trails 23-1

Agenda
Audit Trails
Administrative Information
Deleted Documents
Single Document (getDocumentHistory)
Purge Audit Data

Deletion Holds
Configuring Audit Trails • Slide 2

23-2 710-97
Audit Trails - Overview
Audit of document content lifecycle

Audit is enforced for compliant logical archives
Typical actions to be audited
– Create,copy,migrate,time stamp,delete …
– <Date><Time>
– <log.Archive><documentId><componentId>
– <Volume_1><Volume_2>
Audit of administrative changes

always turned on
Access to audit information

by a tool (for reports) or
by a document based http call to display document information in a leading
application

Idea of an audit is that all activities and changes in the system are tracked and that audit
information can be provided for legal purposes or for documentation.

Collect Audit Data
Collect Audit Data on Documents (Storage)

Collecting audit data for document content lifecycle:
– must be switched on per logical archive
– by activating the Compliance Mode (irreversible)
Each event related to document content is recorded
Stored to a separate database table ds_audit
Collect Audit Data on Administrative Changes (Admin)

always active
Each administrative change is recorded
– same set of events as for the old accounting feature
Stored to a separate database table adm_audit
Manual use of command line utilities (dsTools , cdadm, etc.) not recorded!

Recorded operations are

– related to state changes of the document,
– related to state changes of the components,
– data relevant from the point of view of security,
– concerning the storage.
The retention date is not recorded. Some events may occur even in read-only scenarios (Remote
Standby).
Each event related to document content is recorded:

• CREATE_DOC, UPDATE_ATTR, DOC_SET_EVENT, DOC_MIGRATED, DOC_DELETED
• CREATE_COMP, TIMESTAMPED, COMP_DELETED, COMP_DESTROYED
• TIMESTAMP_VERIFIED, DOC_SECURITY, COMP_DELETE_FAILED,
TIMESTAMP_VERIF_FAILED
• COMP_MOVED, COMP_COPIED, COMP_PURGED
Each event stored to a separate database table ds_audit

• EVENT, TSTAMP
• ARCHIVEID, DOCIDSTR, COMPONENT, VERSION
• VOLID1, VOLID2
• CLNTADDR
23-4 710-97
Access Audit Information –
On Documents & Administrative Infos
Retrieve document audit information:

command line utility exportAudit with option –S
writes output to a file (in <OT var>/audit)
Retrieve administrative audit information:

command line utility exportAudit with option –A
exportAudit -A
(Admin entries)
exportAudit -S
(Storage entries)

Storage options (-S)

– output format: csv, printlist
– show only events concerning deleted documents
– restrict to time frame
Admin options (-A)

– output format: csv only
– restrict to time frame

Purge Audit Data – exportAudit Command
Remove audit data from the database

Command line utility exportAudit with additional option -x
with option –S or –A
removes the listed events from the database
Options: as before
Removing audit data for existing documents is not possible

options –x and –a are mutually exclusive

Purge in this context means the removal of outdated audit entries from the database. This is
necessary to keep the database at a reasonable size.
23-6 710-97
Purge Audit Data – Periodic Job
Schedule job SYS_CLEANUP_ADMAUDIT

to clean old ADM audit entries periodically
command Audit_Sweeper
no Storage audit entries (-S)
Server Configuration: ADMS > Auditing

Configure maximum age of ADM audit entries (-A) to keep

The ADMS job deletes entries that have reached a certain document age. This parameter can be
configured.

On Single Document (1)
Access audit information for a single document:

Dedicated command getDocumentHistory
Available via http API
Can be called by the leading application

23-8 710-97
On Single Document (2)
Retrieve history of a single document via Http API command

getDocumentHistory
Via http or dsh Tool
http://<ArchiveServer>:8080/archive?getDocumentHistory&co
ntRep=<LogicalArchive>&docId=<DocID>&pVersion=0045
C:\>dsh
C:\>dsh -h
-h localhost
localhost
command:
command: getDocumentHistory -a
getDocumentHistory -a H0
H0 -d
-d aaaaf4u1dapuitpitaaaa23azcuma
aaaaf4u1dapuitpitaaaa23azcuma
3(-):
3(-): command
command == getDocumentHistory
getDocumentHistory
3(0): ... call dshDsGetDocumentHistory
3(0): ... call dshDsGetDocumentHistory
3(0):
3(0): ...
... command
command succeeded
succeeded
3(0): ...... CREATE_DOC,1145956615,H0,,0,,,127.0.0.1.1775
3(0): ...... CREATE_DOC,1145956615,H0,,0,,,127.0.0.1.1775
CREATE_COMP,1145956615,H0,dsh.log,1,HDpartition,,127.0.0.1.1775
CREATE_COMP,1145956615,H0,dsh.log,1,HDpartition,,127.0.0.1.1775
CREATE_COMP,1145956615,H0,test.txt,1,HDpartition,,127.0.0.1.1775
CREATE_COMP,1145956615,H0,test.txt,1,HDpartition,,127.0.0.1.1775
COMP_DESTROYED,1145956627,H0,dsh.log,1,HDpartition,,127.0.0.1.1775
COMP_DESTROYED,1145956627,H0,dsh.log,1,HDpartition,,127.0.0.1.1775
COMP_DELETED,1145956627,H0,dsh.log,1,,,127.0.0.1.1775
COMP_DELETED,1145956627,H0,dsh.log,1,,,127.0.0.1.1775

You can access the http API either via http call or using the dsh Tool.

Deletion Holds
In case of a litigation it might be required to disable deletion.

Global Deletion Hold
Valid for the complete archive server
Activated by switching to maintenance mode
Delete attempts are rejected or ignored
Is deactivated during server restart!
Logical Archive Deletion Hold

Valid for the logical archive only
Archive security flag: “Document deletion”
Delete attempts are rejected or ignored
Persistent (survives server restart)

Global Deletion Hold is usually turned off after restart (temporary). It can be configured in Server
Configuration to persistent. You can configure it in
Runtime and Core Services > Configuration > Archive Server:
AS.DS.SYSTEM.DS_RUNLEVEL
23-10 710-97
Exercise: Audit Trails
Get Document History for single

document
Access audit info with exportAudit
Purge audit info with exportAudit
Purge audit data as scheduled job

You can also get document history using dsh Tool:

– Logon to dsh Tool
dsh -h <servername>
– Get document history (i. e. logical archive "H0" and DocID "aaaaf4u1dap...")
getDocumentHistory -a <archive-id> -d <doc-id>

Exercise: Deletion Holds
Put global deletion hold on your

Archive Server
Try deleting a document and verify
results
Prevent document deletion for a

logical archive
Try deleting a document in this logical
archive and verify results

23-12 710-97
24 Backing up the Archive Server
Operative data loss protection
Slide 1
Backing up the Archive Server 24-1

Chapter guide
Hard disk mirroring
Backing up optical media pools: ISO, IXW
Backing up hard disk areas of the Archive Server
Backing up the Archive Server • Slide 2

24-2 710-97
Which HD areas have to be mirrored
(RAID 1 or RAID 5)
Importance of mirroring: Archive Server

4 Strictly required Software Database DS STORM
Prevents data loss installation
3 Strongly recommended WORM

Avoids long recovery 2 2 file system 3
downtimes
2 Recommended
Avoids recovery
downtimes Disk buffer 0
Temp IXW
1 Useful
Avoids temporary
Document
Pipeline
4 media 1
performance
degradation 0 Cache
4 Burn ISO
0 Not necessary buffer media
Contains copies of 4
HDSK
already saved data only
pool 4
HD crash does not affect
DocumentService FS pool
system availability

The basic HD protection rule is: All HD partitions that may hold the only instance of a document
must be protected against data loss by mirroring or RAID.
Suitable techniques to avoid data loss in the instance of a hard disk crash include:
• RAID 1 (= one-to-one mirroring)
• RAID 5 (= striping with parity)
IXOS supports both one with equal preference.
Notes on mirroring specific Archive Server storage locations:

• The document-related data in the ECR database can be entirely restored from the storage
media. However, with a large archive this can be an extremely time-consuming process as
all storage media must be read in again, so the database should regularly be backed up to
tape and/or included in the disk mirroring arrangement.
• Mirroring the cache is advised to avoid reduced performance after the loss of cache, when
all requested documents must be read from storage media again.

Chapter guide
Hard disk mirroring

24-4 710-97
ISO pool backup
Backup disk is created automatically

along with each original disk
Select 2 copies within ISO pool configuration
For each new backup disk:

1. Remove from jukebox
2. Write label on it
3. Store at a safe place


IXW pool backup
Configure
IXW pool:
WORM Jukebox
Select
Select creation
creation of
of
backup
backup IXW
IXW medias
medias
Schedule local backup

job to run daily
Provide backup IXW medias

for new original IXW medias

Unlike backup ISO medias which can be removed from the jukebox immediately after they have
been created, backup IXW medias must reside in the jukebox as long as their original counterpart
is being written to — because the backup IXW media is synchronized with the original
incrementally. As soon as the original has been filled completely and its backup has been
synchronized a last time, the backup can be removed and stored at a safe place.
24-6 710-97
Chapter guide
Hard disk mirroring


Which HD areas have to be backed up
Importance of backup: Archive Server

4 Strictly required Software Database DS STORM
Prevents data loss installation
3 Strongly recommended WORM

Avoids long downtimes 2 3 file system 3
2 Recommended
Allows fast system
setup recovery
Disk buffer 0
1 Possibly useful Temp IXW
Avoids temporary
performance
Document
Pipeline
4 media 1
degradation
0 Cache
0 Not useful 0 Burn ISO
buffer media
Data stored here for a
very short period only, 4
HDSK
or
pool 4
contains copies of FS pool
Document Service
already saved data only

Regularly backing up the diverse hard disk areas used by the Archive Server is a necessary precondition for
data recovery after a hard disk crash. However, such a recovery may serve different purposes:
Disk buffer, hard disk pool: A crash can lead to loss of original documents here, therefore backups are
mandatory for data loss protection.
Database ECR, WORM filesystem: Their contents can be restored from the storage media containing the
actual documents. However, with a large archive this can be an extremely time-consuming process as all
optical disks must be read in again. Backing up these databases helps to restore the system much faster.
• In addition to document management data, the ECR database contains information about the Archive
Server configuration (logical archives, pools, jobs, etc.). This part of the database cannot be
recovered without a database backup! As a consequence of a total database loss, you would have to
recreate your server configuration manually (which is, of course, far less harmful than a loss of
archived documents).
• The WORM filesystem is present on an Archive Server with WORM media only; on other installations,
there is nothing to be backed up here.
Software installation (operating system, database system, Tomcat/Netweaver, Archive Server):
backing up these items helps to recover the whole system rapidly after a crash of the system disk.
Attention: The STORM configuration files are located within the Archive Server Software
installation! (see also page: STORM files backup).
Cache: No data loss can happen here since the cache contains only documents that are already saved on
optical disks. Nevertheless: After a loss of the cache, its whole contents has to be reloaded from the optical
disks upon corresponding retrieval requests; during that period, the server’s retrieval performance would be
considerably degraded. Backing up the cache therefore helps to retain the good system performance across
a cache loss.
Burn buffer, temporary storage for WORM writing: If one of these becomes lost, only write jobs for the
corresponding optical media are disturbed; the users do not even notice such a problem. After mounting a
new hard disk, these write processes can immediately start working anew, no data recovery — and therefore
no backup — is necessary.
DocumentPipeline: Documents normally pass the DocumentPipeline in very short time (seconds or
minutes); moreover, the DocumentPipeline can be backed up in offline state only. As a con-sequence, a tape
backup would never find any data to be backed up and can thus be omitted.
24-8 710-97
FS & HDSK pool backup
Offline backup
Using common backup tools Archive Server
(TSM, Dataprotected, Legato etc.)
Document-
Archive Server services Service
must be shut down
Online backup 4
FS/HDSK pool
For uninterrupted Archive Server operation
Backup tool must not lock files
Pool must comprise two or more partitions. Procedure:
1. Write-lock first partition
2. Back up first partition
3. Unlock first partition
4. Repeat for all remaining partitions
Ensure that no “compress hard disk” job is executed during backup
operation
Does not save consistent state
Incremental backup (= only new/changed files) recommended

Setting partitions to write-locked status can be done manually in the ELS Administration. However,
for an automatic backup procedure, a scriptable way to do this is necessary. The Archive Server
command line tool dsClient (available on every Archive Server) can be used in a Unix shell the
following way:
dsClient localhost dsadmin <dsadmin_password> <<EOT
chgVolS <volume_name> wrlock
end
EOT
volume_name here is the logical name of the partition, as assigned and visible in the Archive
Server Administration. For unlocking the partition, replace wrlock by zero.
For a Windows batch script, you cannot use the <<EOT construct; instead, write the chgVolS and
end commands to a file and invoke dsClient this way:
dsClient localhost dsadmin <dsadmin_password> < filename

Disk buffer backup
Necessary to protect data that cannot

Archive Server
be written to optical disks for more
than a day Document-
For ISO pools with low archiving traffic Service
In case of media write interruptions 4

– i.e. Disk buffer
– broken network connection to storage system
– jukebox damage
– storage system failure
Procedure: Same as for hard disk pools

Cyclic locking of several partitions for backup
During online backup, ensure that no periodic jobs are executed on the
disk buffer:
ISO or IXW write
Purge buffer

24-10 710-97
Database backup
Operate database in archive log mode

All database changes are recorded in Archive Server
archive log files
Archive log files are necessary to recover
Database DS
difference between last full (offline) backup
and status at database failure
3
Back up database files in offline (shutdown) state:
Data files (of all tablespaces)
Redo logs, Transaction logs
Control files DB
DBconsistency
consistencycheck
check
recommendable
recommendableafter
afteroffline
offlinebackup
backup
Back up archive log files at least once a day
Keep archive log files together with full (offline) backup that they start at
For uninterrupted Archive Server operation: Online backup
Done during normal operation, less performance

See also Administration Guide chapter on Backup and Recovery.

STORM files backup (1):
What has to be backed up
WORM file system database

Keeps low-level structure data of IXW volumes Archive Server
Can be recovered from IXW medias in case of loss
Recovery may take very long STORM
(up to several hours or even days,
depending on number of un-finalized IXW medias) 3
Backup strongly recommended WORM
to protect against long downtime file system
Software
installation
STORM configuration and runtime files Runtime
files
Found in <archive_dir>/config/storm
Backed up implicitly when making a software installation backup
Attention: In case you use online backup of the file system of your
software installation, you may run into an error (please see also in the note
part of this page)

Attention: The STORM configuration files are located within the Archive Server Software
installation! Those never must be part of an online backup.
If you use online backup for the software installation the following files to be excluded from online
backup:
• config/storm/*
• all parts of the worm file system (section ixworm of server.cfg)
• including DataFilePath defined in section ixworm of server.cfg
The job Save_Storm_Files will take care of a valid online backup of the STORM files.
Please read also in the ESC:

Storm Terminates and reports "cannot sync. memory map" - "cannot sync. journal file".
24-12 710-97
STORM files backup (2):
Backup methods
Offline backup
When Archive Server (spawner, STORM)
is shut down:
jbdbackup -configRoot=
<archive_dir>/config/storm
(for example)
Online backup
STORM is kept running
IXW medias are read-only during backup
All other system operations continue without restrictions
Accomplished with Save_Storm_Files job in ELS Administration
Both methods create copy of STORM files on local hard disk
Backup destination configured in STORM’s server.cfg file
After backup is made: Store backup files away (e. g. on tape)

Both backup methods mentioned above — the jbdbackup command line utility and the
Save_Storm_Files job in the Archive Server Administration — create a copy of all relevant STORM
files on the server’s hard disks. The destination of this backup copy is specified in STORM’s
configuration file server.cfg (see chapter Where to Find What). Therein you will find a section
like:
backup {
list { dest1 }
backuproot { dest1 }
dest1 {
path { V:/jbd_backup }
size { 1024 }
}
}
Here, V:/jbd_backup is the backup destination directory (which must actually exist when the
backup is started; it will not be created automatically!). Multiple directories may be specified
instead of a single one in order to spread the backup copy over several hard disk volumes; this
way, capacity problems can be avoided in case the WORM database is very huge.
After the backup copy has been made, it is your task to store the backup safely away, preferrably
on a tape.

Software backup
Back up software installation

Once after finishing installation and setup Archive Server
After each configuration change

Software
Attention: installation
The STORM configuration files are located
within the Archive Server Software installation! 2
Those never must be part of an online backup
of the software installation.
(see also page: STORM files backup)
Back up:
Operating system
Archive Server software and configuration
Database system software and configuration

24-14 710-97
25 Hard Disk Resource
Maintenance
Adding hard disk space to Archive Server
resources as needed
Slide 1
Hard Disk Resource Maintenance 25-1

Chapter overview
Enlarging hard disk space for:

Disk buffer
FS/HDSK pool Storage STORM
database
Cache DS WORM
filesystem
DS database Document
Pipeline
WORM FS database Disk buffer
Temp IXW
DocumentPipeline pool
Burn buffer Cache

Burn ISO
“Temp” space for buffer pool
IXW writing
Document
Archive
Archive Service FS/HDSK pool
Server
Server
Hard Disk Resource Maintenance • Slide 2

25-2 710-97
Disk buffer
Disk buffer needs more space when archiving traffic increases

Higher average archiving rate
Higher archiving volume peaks
More logical archives (with ISO media pools) using the same buffer
Ways to provide more space for disk buffer:

Enlarge current hard disk partition (if operating system permits this)
Attach additional volume (→ next page)
Do not make partitions too large

Too many documents on a volume may lead to performance problems
– During disk buffer purging
– During volume consistency checks

Detecting disk space shortage of disk buffers is fairly easy: The Archive Server Monitor shows a
warning state if the free space of a buffer is less than 30% of total space. (This threshold
percentage may be altered if it is unsuitable.)
The recommendation not to use too large hard disk partitions is due to the fact that some
administrative actions (like disk buffer purging or consistency checks) require examining the whole
volume contents. The more documents are stored there, the longer such a scan will take. If,
moreover, a partition is full of very small documents, the total number of files is very high; this may
lead to unacceptably long execution times of those actions. To prevent this type of problem, rather
use multiple partitions of moderate size instead of a single large partition. If you store rather large
documents only (like SAP data archiving files), the partitions may be made larger as well; where
mainly small documents are stored, the partition sizes should be smaller (using BLOBs, however,
reduces the number of stored files of small documents).

Add hard disk volume to disk buffer

To add an additional hard disk volume to a hard disk pool or buffer, you first have to provide a hard
disk partition on operating system level. On a Unix-based Archive Server , make sure the root
directory of the file system is owned by the user/group that the Archive Server is operated as (e. g.
ixosadm/ixossys) and has permissions 770.
Once the disk volume is prepared, continue with the steps illustrated above:
Make the new volume known to the Archive Server by invoking the “New Volume...” dialog
as illustrated above. (The term “Create …” is actually misleading here; you cannot create a
volume from within the Archive Server Administration.) Specify the following:
Volume name: An (Archive Server -internal) logical name for the volume; must be
unique throughout all volume names (including IXW medias) of this Archive Server .
The Archive Server will henceforth maintain the volume by this name.
Mount path: The root directory of the volume’s file system. On Windows NT, this should
be a drive specification (including a backslash); on Unix platforms, it is the directory
where the volume is mounted; up from Windows 2000, it can be either of both,
depending on how the volume is hooked into the file system.
If, on a Windows-based Archive Server , you want to use a network share instead of
a local hard disk drive, see KC article
7080 about how to do that exactly.
Volume class: Choose "Hard Disk" for a local disk.
Assign the prepared hard disk volume to the disk buffer by means of the “Attach Volume..."
dialog as illustrated above.
In case of a hard disk pool instead of a disk buffer: Within Archive Server Administration’s
logical archives list, select the hard disk pool that the volume shall be added to; then invoke
the “Attach volume to Buffer" dialog as illustrated above.
25-4 710-97
FS & HDSK pool
FS & HDSK pools need more space when total amount of stored data is
about to exceed assigned disk space
Providing more space for FS & HDSK pool:

same as for disk buffer
Enlarge current hard disk partition (if operating system allows this)
Attach additional volume (→ previous page)
Do not make partitions too large

Detecting disk space shortage of hard disk pools is fairly easy: The Archive Server Monitor shows
a warning state if the free space of a pool is less than 30% of total space. (This threshold
percentage may be altered if it is unsuitable.)
Assumption for FS pool is that it is using local hard disk only. Sizing an FS pool that is working with
a sophisticated storage system may differ.

DocumentService Cache
Cache needs more space when documents are deleted from cache too
early
Ways to provide more cache space:
Enlarge current hard disk partition (if operating system permit this)
Assign additional volume:
1. Provide a volume for exclusive use by the cache
volume will become filled up completely
2. Add drive letter or mount point to cache volume list
3. Change will be effective after next Archive Server restart
Do not make volumes too large

Use several volumes of moderate size
Helps troubleshooting consistency problems

The recommendation not to use too large hard disk partitions bears an advantage in
situations where the cache index — due to whatever reason — has become damaged. Such a
cache index problem is normally restricted to a single cache volume, and a common solution is
deleting all contents of this cache volume. If the cache consisted of just one single large volume,
you would lose the whole cache contents by this action (which does not mean real data loss; only
the cache would have to be filled again by subsequent document read requests, during which your
server’s performance would be impaired); a cache consisting of several smaller volumes would
only lose a small part of its total contents.
In Archive Server ≤ 9.6.0, when adding additional hard disk to local cache, all contents of the
current cache will be discarded!
In Archive Server ≥ 9.6.1, this problem no longer exists due to new caching technology used.
Additional hard disk can be added to local cache without losing previous content.
25-6 710-97
Create New Cache
Add additional
hard disk partitions
if needed

Besides a Global Cache, you can create different caches for specific logical archives.

Assign Cache to an Archive

In the Infrastructue > Caches section, select a specific Cache Name to see where it is used.
25-8 710-97
Databases: DS, WORM filesystem
DS database
See Archive Server Monitor for filling rate
If too small: Enlarge with database tools

See Archive Server Monitor for filling rate
If too small:
– Try to reduce data by finalizing IXW medias; if that does not help:
– Call OpenText Support for enlarging


Unfortunately, no easy way to enlarge this resource exists. Nevertheless, it is possible to recreate
it from scratch and to reimport all IXW medias into it. Since this is a very time-consuming activity
during which IXW media access is not possible, a special, quite complicated workaround should be
applied. Please contact OpenText Support for help in this situation.
On the other hand, the WORM filesystem should nowadays no longer become filled up as filled
IXW medias can be finalized, keeping the WORM filesystem’s filling rate on a rather constant level.

Other HD resources
Resource Needs more space if …
DocumentPipeline directory DocumentPipeline workload increases (average or peak)
“Temp” storage for WORM
Single archived files are too large to fit into it
writing
Introducing larger ISO media (i. e. HD-WO)
More ISO write jobs shall be executed simultaneously
ISO burn buffer
More ISO images shall be cached for later backup
(“asynchronous” local or RemoteStandby)
For these resources, no special enlargement methods exist

Enlarge current HD partition online, if possible
Enlarge “offline” otherwise:
1. Shut down Archive Server
2. Save content away (e. g. on tape)
3. (Re)create larger partition
4. If new volume has different mount point / drive letter: adjust Archive Server
configuration
5. Restore previous content to new volume
6. Start Archive Server
25-10 710-97
Exercises
Add second volume

to disk buffer
Initialize new volume
Assign to disk buffer
Advanced exercise:
Enlarge DocumentPipeline directory
Move DocumentPipeline directory to
larger partition
Take care to save contents across
change
Adjust DPDIR setting in Archive Server
configuration
– Pay attention to configured and
implicit directory structure
Continue processing of saved
processing items


25-12 710-97
26 Statistics and Accounting
Information
Various kinds of Archive Server usage
information
Slide 1
Statistics and Accounting Information 26-1

Chapter guide
DocumentService statistics
STORM statistics
Accounting Information
Statistics and Accounting Information • Slide 2

26-2 710-97
Read/write statistics for storage media
Counters for read and write requests per medium

Retrieve with dsClient:
stat RC volume (read access)
stat WC volume (write access)
Useful information
Which media are no longer accessed by users?
Decide which media to remove from jukebox when space for new media is required
dsClient
dsClient hostname
hostname dsadmin
dsadmin password
password
-> stat RC volume
-> stat RC volume
## volume
volume write
write read
read wrblks
wrblks rdblks
rdblks
Diskbuf1
Diskbuf1 0 1109
0 1109 00 86025
86025
FI_001A
FI_001A 00 00 00 00
FI_001B
FI_001B 00 54
54 00 3045
3045
FI_002A
FI_002A 00 543
543 00 75432
75432
FI_002B
FI_002B 00 1565
1565 00 976735
976735
FI_003A
FI_003A 0 643
0 643 00 86574
86574
FI_003B
FI_003B 00 00 00 00

Please use the stat command carefully and validate its results.

Statistics about reading
from cache / jukebox / hard disk
Accumulated counters for access to cache / opt. media / disk buffer

Useful information
Is caching configured appropriately for fast document access?
Is the cache large enough?
Retrieve with dsClient:

stat RC read
dsClient
dsClient hostname
hostname dsadmin
dsadmin password
password
-> stat RC read
-> stat RC read
#sum
#sum Reads:
Reads: MByte
MByte KByte
KByte Bytes
Bytes
1658
1658 361
361 474
474 Amount of data
#cache Reads: retrieved from …
#cache Reads: MByte
MByte KByte
KByte Bytes
Bytes
835
835 43
43 469
469 … cache
#noncachable
#noncachable Reads:
Reads: MByte
MByte KByte
KByte Bytes
Bytes
574
574 432
432 543
543 … disk buffer / HDSK pool
#direct
#direct Reads:
Reads: MByte
MByte KByte
KByte Bytes
Bytes
248
248 909
909 486
486 … jukebox

The comparison between the data amount read from optical media vs. from hard disk resources
(disk buffer, HDSK pool, cache) indicates whether the server uses these resources efficiently. The
general rule is: The “direct reads” amount should be low compared to “cache reads” plus “non-
cacheable reads”.
The absolute numbers and ratio, however, are not very useful for a judgment; they are too
dependent on how the Archive Server is used (leading applications and storage/retrieval
scenarios). You can though perform a long-term observation to see whether the ratio changes over
the time. If the relative amount of “direct reads” increases, you should consider improving the
caching setup. Possibilities include:
• Enlarge the cache.
• If documents are cached in the disk buffer (see chapter Disk Buffer Configuration), extend
the buffer retention period in the buffer purge configuration.
• If caching after media writing or caching before buffer purging are deactivated, activate the
appropriate option.
• If caching is deactivated as config option for a logical archive, activate it.
The decision what to do depends on the exact Archive Server configuration and usage context;
profound knowledge of this context is needed to make a well-founded decision.
26-4 710-97
DS statistics: technical aspects
How the DS keeps the statistics

Values are kept during runtime
Values are dropped at shutdown, reset at startup
Can be reset manually at any time
Recommended use
Retrieve a statistics report regulary, e. g. daily
Retrieve report directly before regular maintenance shutdown
Make your own evaluation using your preferred tools
Because statistics are reset during each restart, this tool is not
recommended for capturing a complete & reliable statistic evaluation.
Contact OT Global Services for such solutions.
Reset statistics
In dsClient:
stat RC readclear
stat RC volumeclear
stat WC volumeclear
Moreover, statistics are reset at each Archive Server restart

The explanations given above apply to the types of statistics discussed on the previous pages.
Generally, the DocumentService maintains a lot of other statistics as well; those explained here
are the ones really useful in normal administrative practice.

Chapter guide
STORM statistics

26-6 710-97
Statistics for jukeboxes, drives,
media
STORM writes statistics information to a file
Usefulness:
Are enough drives available for efficient media access?
Keep track of hardware wearout, especially of jukebox robots
– Anticipate need for hardware maintenance (“early watch”)
.ini-like statistics file format

Perl script available to convert statistics.txt
to a well-readable HTML file;
can be customized for customer needs
Interpretation of statistics information

is not covered by OT support contracts


Structure of STORM statistics files
Number
Number of
of disk
disk inserts
inserts
Number
Number of
of disk
disk moves
moves Number
Number of
of disk
disk ejects
ejects
[[ box
box ]]
id
id == CD_1
CD_1
changer
changer == 516130
516130 40
40 00 22 11
drv_0
drv_0 == 516133 00 15
516133 15 Data
Data volume
volume written/read
written/read (MB)
(MB)
...
...
[[ endsection
endsection box
box ]]
[[ volumes
volumes ]]
08fc934b
08fc934b == LF_01A.bk1
LF_01A.bk1 1313 1042624268
1042624268 1954
1954 11 84 84 00 11
13c62764
13c62764 == A2_001A
A2_001A 77 1047888995
1047888995 44 15
15 1425
1425 00 00
...
...
[[ endsection
endsection volumes
volumes ]]
...
...
Volume
Volume creation
creation time
time No.
No. of
of access
access requests
requests while
while No.
No. of
of access
access requests
requests while
while
medium
medium was
was not
not available
available in
in drive
drive medium
medium was
was available
available in
in drive
drive

Meaning of the figures listed in the statistics file (after the ‘=’ sign, from left to right):
Changer (robot) information:
1. Online time of jukebox (seconds)
2. Number of disk moves
3. Number of failed moves recovered by STORM
4. Number of disk inserts
5. Number of disk ejects
Drive information:
6. Online time (seconds)
7. Data volume written (MB)
8. Data volume read (MB)
Volume (medium) information:
9. Checksum of volume ID (before the ‘=’ sign)
10. Volume name (High Sierra)
11. Volume ID
12. Volume creation time (Unix timestamp)
13. Online time of medium (seconds)
14. No. of access requests while medium was not available in drive (expressed as
number of NFS data blocks of 8 kB)
15. No. of access requests while medium was available in drive (expressed as number
of NFS data blocks of 8 kB)
16. Data volume written (MB)
17. Data volume read (MB)
See the Archive Server Administration Guide for a complete statistics file documentation.
26-8 710-97
Statistics file processing
STORM
Writes every
10 minutes jbd_stat.1047888469
(by default)
jbd_stat.1047894530
Renames, collects
at startup
jbd_stat.1047895276 statistics.txt
jbd_stat.log ADMS job Compress_Storm_Statistics
accumulates data into single file
Reset statistics:
Delete collected file(s) jbd_stat_<timestamp>
Delete accumulated file statistics.txt
Edit files manually, set specific values to zero (no built-in reset
function yet)

• Per default, all STORM statistics files are written and collected in directory
<OT var>/stats.
• Configuration parameters for STORM statistics collecting can be maintained in the
<OT config AS>/storm/server.cfg

Chapter guide
STORM statistics

26-10 710-97
Access logging by Archive Server
Archive Server logs all access traffic, with

certain restrictions:
Ony requests via HTTP interface only
– Requires activation for some leading systems
and Archive Clients
Only requests answered with HTTP_OK
– Requests resulting in errors are not logged
Only when switched on
Data is stored in files:

<OT var>/acc/<date>_<comp>.acc
One file per day and per component (RC, WC)
Path may be altered
(e. g. to point to a separate file system)

You can change the Accounting settings in <OT config AS>/setup/DS.Setup

Note: If you do not intend to make use of the accounting functionality, you should disable it
completely (it is enabled by default) as described above!

Using retrieved accounting data
for billing
Customer analyzes accounting information

using preferred calculation tool
MS Excel, MS Access, …
Logged accounting data useful for that purpose:
Parameter Example Meaning Useful for

RequestTime 156 Milliseconds needed to Billing by
serve request server workload
ContentServer DA Addressed Grouping the billing by
logical archive logical archives
and, finally, customers
UserId 149.235.50.215.2 User name, if known; Billing by number of
0030116.15.03.18 cookie ID otherwise active users
ContentLength 45372 Number of transferred Billing by
bytes traffic volume

The table above mentions those pieces of accounting data that are useful for billing. Additionally,
the following items are logged for each request:
• TimeStamp — when did request take place?
• JobNumber — classification of requests
• ClientAddress — IP address of client or intermediate proxy server
• ApplicationId — name of IXOS (or other) application that sent the request
• NumComponents — number of transmitted (send or received) document components; one
of 0, 1, or 2
• DocumentId of requested document; (for document-related requests only)
• ComponentId — name of transmitted component (for data transmission requests only)
26-12 710-97
Reorganization of “old”
accounting data
Accounting data directory must be cleaned up regularly

Done by periodic job Organize_Accounting_Data
Schedule job to run once after each accounting period
Possibilities
Keep: useful only if you want to manage old files yourself
Delete: useful if you keep downloaded CSV files somewhere
Store in a logical archive: useful in all other cases

Unless collecting accounting data is disabled (see earlier in this chapter), the directory where the
data files are stored will normally be filled with huge amounts of accounting logging quite fast.
Deleting or moving away those files which have already been used for billing is therefore a
mandatory regular task of Archive Server operating.
However, this task can be automated by the predefined periodic Archive Server job
Organize_Accounting_Data which can be configured in <OT config AS>/setup/DS.Setup
Notes about the Pool for the accounting data parameter:
– It is not explicitly set and therefore not displayed by default. To have it displayed,
choose menu item View → Display undefined values.
– It expresses the storage destination used if the reorganization method “archive into
given pool” is chosen.
– It must follow the syntax <archive_ID>_<pool_name>; in the example displayed
above, A4 is the logical archive ID and the archive’s pool is named WORM.
Accounting data files which have been stored in a media pool (preferrably on optical media) can
later be restored to their original location using command line tool dsAccTool -r.

26-14 710-97
27 Logfiles and Loglevels
Managing and using Archive Server
logging output
Slide 1
Logfiles and Loglevels 27-1

Chapter guide
Structure and relationship of log messages
Working with loglevels
Size limitations for logfiles
Relevant logfiles
Logfiles and Loglevels • Slide 2

27-2 710-97
Log message structure (1): General
Line-wrapped appearance
in text editor
Message type according to log switch name

ERR
Relevant types for troubleshooting:
IMP INF WRN ERR FTL SEC
08.11.00 10:05:19.920
Date and time of log entry
11 .. LocClnt::statfs
LocClnt.cxx-488 Log entry origin (module, funct. name,
source file name, line number)
No such file or directory: Relevant for IXOS developers only
statfs(\\muc01010\temp\form)
returns errno 2 Log message text

The chart above explains an example of a typical log message. The structure is the same for most
Archive Server log files; exceptions are detailed later in this chapter.

Log message structure (2):
STORM trace file
Message class (Error, Warning, …) E

or log level at which the entry was issued
Date and time of log entry 2002/07/11 11:45:10:250
Type of activity that caused the entry
E.g.: ‘@’ = disk drive access @
Request number (may be empty) 00 07
Helps filtering long log files for
messages belonging to a certain incident
"scsi"
STORM component issuing the message
Source file, line number "open.c" 425
For IXOS-internal debugging only
Log message text scsi_open(\\.\p4b0t4): open failed

The request number mentioned above is assigned by STORM arbitrarily to each client request that
cannot be fulfilled immediately. For example: If all disk drives are occupied, the next incoming data
read request is queued for later processing and is assigned such an internal request number.
Since STORM handles multiple pending requests in a parallel manner, log messages of concurrent
requests occur interwoven in the log file. Nevertheless, it is easy to filter out all messages
belonging to a certain request by searching log lines for the request number.
27-4 710-97
Log message interrelations (1):
Within a log file
Often an earlier message tells why a later error has occurred
Example:
This
This earlier
earlier message
message reveals
reveals
the
the failure
failure reason
reason
IMP 05.08.03 14:29:40.109 ... Prepdoc started, 5.5.2002.1206

WRN 12.08.03 16:31:26.078 ... callHttpGet('http://xtarclo:,...) failed
FTL 12.08.03 16:31:26.078 ... cannot get a new document id; the call of
function dshDsReserveDocId() failed: 'HTTP error
(unauthorized [401]): Breach of security:
URL='http://xtarclo:8080/archive...''
IMP 12.08.03 16:31:26.078 ... Can't get document ID from archive ID 'DEMO'
ERR 12.08.03 16:31:26.078 ... can't get DOCID for archive ID 'DEMO', in
docpath 'xtarclo/m/1060698680.b000'
IMP 12.08.03 16:31:26.078 ... Error on document 'xtarclo/m/1060698680.b000',
'error', 'cannot get DocID with ArchivID = DEMO'
Messages
Messages with
with identical
identical time
time label
label This
This final
final error
error message
message denotes
denotes
normally
normally belong
belong to
to the
the same
same incident
incident that
that an
an action
action has
has failed
failed

Often an operational problem is due to some malfunction or misconfiguration that takes effect
earlier within the processing sequence of an operation. This is reflected within the log files: The
final error message tells what kind of operation could not be fulfilled — but, in order to find the true
reason for the failure, you have to scan through the preceding messages, too; one of them may
reveal the decisive information for diagnosing the problem.
The log messages’ time label can provide valuable help in this respect. In many cases, you may
restrict your search for relevant information to the range of messages with a time statement
(nearly) identical to the time of the error message in question; those messages reveal the
operation history that took place immediately before the failure occurred.
The example above is taken from the log file of the DocumentPipeline tool Prepdoc whose task it
was to reserve a document ID for a document being processed in the pipeline. The
DocumentService rejected this request as being unauthorized — the security options of the target
logical archive required signatures for all kinds of access requests, which the DocTool was not
configured to deliver.

Log message interrelations (2):
Across log files
A system component may fail due to a previous failure of another

component
Example:
2 2001/03/28 17:06:04:497 @ 00 Cannot read at x0

4 2001/03/28 17:06:04:497 @ 00 scheduler - possibleFaultyDrive
(Info): drive 1 of cdrom cannot
jbd_trace.log identify slot 7
... ...
1 2001/03/28 17:08:14:284 @ 00 scheduler - phiIsBad (Info):
removing cdrom[7] from all views
ERR 28.03.01 17:08:14.284 08 .... NfsClnt::stat NfsClnt.cxx-693

No such device: stat(CDROM\
RC1.log iXOS_A0_CD_Pool_0001A\.\00\07
0000032E\1.PG;1) returns
error 19(No such device)
IXClient.log ERROR 2001/03/28 17:08:15:828 ... CDMSRpcClient::GetDocumentInfo();

(not on the ::GetDocumentInfoEx() failed!
Achive Server)

Often an error becomes visible at some system component but has been caused by a different
one. The example above shows how the jukebox server STORM fails to read a document from a
CD, probably because the CD is damaged (top). The DocumentService’s read component —
which has requested this CD reading operation from STORM — writes a message about the failure
in its own log file (middle). Finally, the Archive Client which originated the retrieval request is
informed about the reading failure and writes a log entry about not being able to retrieve the
document to the client-side log file (bottom).
For troubleshooting purposes, you examine the log files the opposite direction: You begin with the
one nearest to the error occurrence (the client log file in the above example) and proceed to the
one(s) of the underlying components. In this case of synoptically log file analysis, it is essential that
you pay attention the log messages’ time labels in order to track their causal relationship.
Common “causal connections” between messages of different log files include:
• Document storage from Enterprise Scan:
doctods.log (on scanning client) — WC.log
• Document storage via DocumentPipeline:
doctods.log (on Archive Server) — WC.log
• Document retrieval:
IXClient.log (on retrieval client) — RC1.log — dscache1/2.log —
jbd_trace.log
• ISO media burning:
admsrv.log — dsCD.log — jbd_trace.log
• IXW media writing:
admsrv.log — dsWORM.log — jbd_trace.log
27-6 710-97
Chapter guide
Relevant logfiles


Static vs. dynamic loglevel settings
Static Dynamic
(a. k. a. “persistent”)
Stored as configuration parameter Given as command to a running process
Becomes effective when Becomes effective immediately

related process is restarted
Is retained at process or machine restart Is lost when process terminates
Must be set back to original value explicitly after Should be set back to original value after
troubleshooting troubleshooting if system operation shall not be
interrupted
Useful for longer running Useful for instant observations of specific

system behavior observation operations
Not applicable to all Archive Server components
Both can be combined to achieve an immediate and permanent change

27-8 710-97
Log switches (1)
Determine what kind of information is written to logfiles

To be set per function component (DS, ADMS, BASE, …)
Dynamic setting possible for some components
Example: Log settings for DocumentService
Log settings per

Archive Server component

Every functional component of the Archive Server (as discussed in chapter Archive Server
Architecture) has its own set of log switches, enabling to control the amount and focus of logging
output quite precisely. (See next page about the available log switches and their meaning.)
The preferred tool for viewing and changing log settings in the Server Configuration page of the
Archive Server Administration (illustrated above). Each folder containing log settings is located
underneath the Archive Server component the settings belong to.
Setting log switches dynamically, however, is possible in the Server Configuration page for only a
subset of the server components (including DocumentService and AdministrationService). For
some of the components, command line tools are available for viewing and setting log switches
dynamically:
• Document service’s read and write components (RC1–4, WC): dsClient
• Document pipeline DocTools: dpctrl
See appendix Archive Server Command Line Tools for details.

Log switches (2)
Log switches relevant for troubleshooting:

LOG_INFO Logs read configuration entries Most useful one for troubleshooting
and received commands Helps detecting configuration faults
LOG_WARNING Logs conditions possibly Should always be activated

causing problems
LOG_DB Logs all database access of Caution: High amount of logging output →
server components huge log files, performance loss
LOG_HTTP_DATA Traces data transmitted via For DocumentService only
HTTP
LOG_REL Relative (instead of absolute)
time indications in log files
Some log switches are always active:

LOG_ERROR Errors
LOG_FATAL Errors leading to process termination
LOG_SECU Security violations
Other log switches are relevant for OT developers only

27-10 710-97
STORM loglevels
Individual numeric log levels for

STORM components
Possible values: 0, …, 4
Static and/or dynamic setting possible

in server.cfg
path: <archive_root>/config/storm/
Use in cooperation with OT Support

STORM’s loglevels can be accessed the following way:

• Static log settings are stored in STORM’s configuration file:
Win: <archive_root>\config\storm\server.cfg
Unix: /usr/ixos-archive/config/storm/server.cfg
Entries: loglevels { <component> { <log_level> } }
• Dynamic log settings can be set and queried with command line tool cdadm; see
appendix Archive Server Command Line Tools for details.

Chapter guide
Relevant logfiles

27-12 710-97
Size limitations for logfiles (general)
When logfile reaches size limit:

<filename>.log → <filename>.old
– Old <filename>.old is dropped
New <filename>.log is created and written into
Configure
size limit
component-wise:
Global
Global settings
settings are
are effective
effective
for
for components
components
without
without individual
individual settings
settings
Spawner logfile spawner.log:

Dropped and recreated at every spawner startup


Size limitations for STORM log
and trace files
When file reaches size limit and at every STORM startup:

<filename>.log → <filename>.000 → ….001 → … → ….0xx
– Old <filename>.0xx is dropped (maximum for xx ≡ 99)
New <filename>.log is created and written into
Applies to files:
jbd.log — “standard” logfile with unified logging format
jbd_trace.log — trace file, more detailed than standard logfile
jbd_lwords.log — “last words”, debugging aid when STORM has crashed
Configure
size limits:

27-14 710-97
Chapter guide
Relevant logfiles


Relevant logfiles for Archive Server Operations
Burning ISO images / writing to Purging disk buffer

IXW medias dsHdskRm.log
dsCD.log / dsWORM.log jbd_trace.log
jbd_trace.log Document retrieval

IXClient.log (on retrieval client)
Backing up IXW medias
RC1.log
bkupDS.log
dscache1/2.log
bkupSrvr.log jbd_trace.log
bkWorm.log
Write to VI pool
jbd_trace.log (Single File – Centera)
Finalizing IXW medias dsGs.log
dsFinalize.log Write to FS pool

jsd.log (buffered hard disk)
dsHdsk.log
jbd_trace.log

For problems with storing documents, check also WC.log.
The VI pool is used for writing single files to a EMC Centera storage system.
The FS pool is the successor to the HDSK pool and supports the disk buffer.
.
27-16 710-97
Logging:
Further sources of information
Complete description and explanation of log settings

Archive Server Administration Guide,
chapter Troubleshooting/Analyzing problems
You may find Archive Server Administration Guides in

Knowledge Center:

Archive Administration Guide in KC:

The following documents are related to older Archive Server versions. Nevertheless, may contain
valuable information.
Archive Server Troubleshooting Tools in ESC (≤4.x):
Log files and error messages:

27-18 710-97
28 Summary of troubleshooting
tasks on Archive Server
… before it is too late!
Slide 1
Summary of troubleshooting tasks on Archive Server 28-1

Chapter overview
Avoiding problems
Examining error symptoms
Finding proper log files for further information
Contacting OT Support
Summary of troubleshooting tasks on Archive Server • Slide 2

28-2 710-97
Avoiding problems
It is still the better strategy to avoid problems than

to solve problems
Some general hints
Make backups of the Archive Server — including its database — regularly
Test restoring of backups
Monitor the Archive Server
Test whether it is possible to restart the Archive Server without problems
Follow recommended Archive Server upgrades (see ESC)
Install necessary patches (see KC)
Verify compatibility of used products & components (see KC)
Train your IT staff
Train your scanning personnel (if applicable)
Hardware and software service contracts can help

Find Archive Server Patches in KC:

Product Compaibility Matrix in KC:

Release and Phase Out Dates for archive-based products in ESC:


Symptom examination (1):
Error state (“red bulb”) in Server Monitor
Categories of error conditions:

Disk/database space shortage
→ Examine whether
– disk is too small for normal operation, or
– data has queued up irregularly
Program terminated
Message: “Can’t call this server”
→ Consult program’s log file;
log file name is equal or similar
to program name
Item in DocumentPipeline error queue

→ Examine DocumentPipeline using
DocumentPipeline Info
Consult
Consultsection
section
Using
UsingMonitor
MonitorWeb
WebClient
Client
of
ofAdministration
AdministrationGuide
Guide
This and the following pages explain how to investigate error states by deducing possible error
causes from the visible error symptoms. Since it is impossible to list all imaginable malfunction
reasons, the explanations concentrate on the first investigation step from the error cause to a
resource for more detailed error information. This more detailed resource will mostly be some log
file; the IXOS log files usually give decisive hints about where to look for the true error cause, so
this should be sufficient in the context of this course.
Depending on the category of the error indicated in the Archive Server Monitor, there are different
ways of examining possible causes, as explained above.
Concerning the correspondence of program names and log file names, see the following page. The
only exception lies in the “Storage Manager” branch of the monitor tree: STORM’s log file is named
jbd.log, and the trace file jbd_trace.log should also be examined for troubleshooting.
For an explanation about examining DocumentPipeline error items, see page Symptom
examination (4): DocumentPipeline errors later in this chapter.
For further information see the section Using Monitor Web Client in the Archive Server
Administration Guide in Knowledge Center (KC):
28-4 710-97
“Dead” services in spawncmd status
On the Archive Server,several terminated processes in the

spawncmd status list are the normal state
If more than those are terminated → consult their log files
C:\> spawncmd status

Terminated
Terminated irregularly
irregularly
(exit code ≠≠ 0)
(exit code 0) program-id sta pid start time stop time
------------------------------------------------------------
Log
Log file
file name
name similar
similar Clnt_dp R 526 07/24/2001 13:47:31
to program-id
to program-id admsrv T 1 07/24/2001 13:47:31 07/24/2001 19:21:47
bksrvr R 178 07/24/2001 13:47:31
chkw T 0 07/24/2001 13:47:35 07/24/2001 13:47:35
cpfile R 328 07/24/2001 13:47:35
db T 0 07/24/2001 13:47:35 07/24/2001 13:47:36
doctods R 336 07/24/2001 13:47:36
dp R 514 07/24/2001 13:47:36
dsrc1 R 353 07/24/2001 13:47:38
dsstockist T 0 07/24/2001 13:47:38 07/24/2001 13:47:39
These are dswc R 348 07/24/2001 13:47:38
allowed to rfcS46 R 397 07/24/2001 15:10:56
be terminated stockist T 0 07/24/2001 13:48:40 07/24/2001 13:48:40
with exit code = 0 testport T 0 07/24/2001 12:47:10 07/24/2001 13:47:10
wfcfbc R 504 07/24/2001 13:48:40

In a sane operational state, all Archive Server processes listed in spawncmd status have to be
running — except for the ones marked in the chart above. If any of the other programs is marked
as terminated (’T’ in column “sta”), something irregular has happened to them. To investigate this,
you will have to have a look in the corresponding log file. Each of the listed programs writes to a
log file whose name is similar, yet not always exactly equal, to the displayed program name. Some
important examples:
admsrv → admSrv.log
dsrc1 → RC1.log
dswc → WC.log
On a scanning station with EnterpriseScan installation, a subset of the Archive Server processes is
installed and must be running as well. There, stockist is the only program that is allowed to be
terminated during normal operation.

Symptom examination (3): Red bulb in Archive
Server job protocol
Job
Job program
program name
name Mostly
Mostly some
some diagnostic
diagnostic
equals
equals log
log file
file name
name note
note already
already here
here

The Job Protocol window (shown above) of the Archive Server Administration indicates
unsuccessfully finished periodic jobs by red bulbs in the leftmost column. There are three
possibilities to gather information about possible causes:
• The protocol item itself mostly yields some brief note about what has gone wrong.
• You may click on the protocol row in question and then click the Messages button. In the
window pane below, messages related to the chosen job will be shown.
• In case you need to examine messages of earlier job runs, you will have to consult the
corresponding log file. The log file’s name can be deduced from the protocol entry: It is
mostly equal to the job’s program name mentioned in the protocol window’s “Message”
column.
28-6 710-97
DocumentPipeline errors
DocumentPipeline Info
Document log
DocTool
DocTool name
name
equals
equals log
log file
file name
name

The DocumentPipeline Info shows the processing status of documents being processed. If
some document is being held in an error queue (see illustration above), there are two
possibilities to gather information about possible causes:
• Within the DocumentPipeline Info window, click on the row containing the document in
question (“Archive document” in the example above); the window’s status bar then displays
the name of the DocTool at which the error has occurred (“doctods” in the example above).
You may then consult the log file with exactly that name (with .log appended); it will reveal
meaningful messages about the error(s) in question.
• A way to get information directly within the DocumentPipeline Info, yet often less
informative:
1. Right-click the row containing the document in question. From the context menu,
choose Documents Show.
2. The first time you do this within a DocumentPipeline Info session, you will be
prompted to log on to the DocumentPipeline as an Archive Server administrator.
3. Beneath the chosen DocumentPipeline row, a sub-list is displayed containing all
documents currently being kept at this processing step. Right-click on one of the
documents in question and choose Protocol from the context menu; this will open
a window showing just that portion of the DocTool log file concerning the chosen
document (shown above, top right).

Further Information
Find information about known problems

in the Knowledge Center (KC): http://knowledge.opentext.com

Content from former IXOS Expert Service Center (ESC) has been migrated to KC.
28-8 710-97
Contacting Customer Support
If you need support …
… the Support Hotline

will always help you!
Contact Customer Support (Hotline)

Global Support Centers
– Germany
– UK
– Americas
– Asia & Australia
– Japan

For information about contacting the Open Text Support Centers, see:
http://www.opentext.com/2/global/services-home/services-support.htm

28-10 710-97
Appendix A
Exercise Worksheets
Overview
Exercise 1: Storing and retrieving a sample document

Exercise 2: Using the Knowledge Center
Exercise 3: Writing stored documents to WORM
Exercise 4: Examine a document on storage media
Exercise 5: Finalizing a WORM
Exercise 6: Create logical archive on Archive Server
Exercise 7: Create disk buffer
Exercise 8: Store and examine a document in a BLOB
Exercise 9: Store and examine a single-instance archived document
Exercise 10: Retention Settings
Exercise 11: Archive Server components
Exercise 12: Check operating condition and restart Archive Server cleanly
Exercise 13: Archive Server monitoring
Exercise 14: WORM operating
Exercise 15: Volume migration
Exercise 16: Volume export and import
Exercise 17: Check consistency of storage volume and database
Exercise 18: Remote Standby configuration and operating
Exercise 19: Scheduling periodic jobs
Exercise 20: Audit Trails
Exercise 21: Deletion Holds
Exercise 22: Online backup of WORM filesystem database
Exercise 23: Add partition to disk buffer
Exercise 24: Move DocumentPipeline directory
Exercise Worksheets Appendix A-1

Servers, Users & Logins
Participant Computer Name : ________________________________
Participant Computer Login : ________________________________
Participant VMware Login : ________________________________
Archive Server : ________________________________
Variables:
<OT var>
C:\Documents and Settings\All Users\Application Data\Open Text\var
Appendix A-2 710-97

Exercise 1: Storing and retrieving a sample document
Scenario: During this course, you will practice working with the Archive Server. Most of the
server’s functionality has to do with documents somehow. For these reasons, you
will need to store example documents for some of the following exercises.
Your task: Scan a given sample document and store it in your classroom Archive Server.
Afterwards, find the document in the archive and display it in the Archive Viewer.
If there is a leading application is involved (i. e. SAP system), your trainer will provide you with
necessary additional information.
Steps
1. “Scan” the document
Directory for file input: \\<trainer_host>\scandocs\group##\invoice
2. Store the document in logical archive A# of your Archive Server

3. Retrieve and display the stored document

Exercise 2: Using the Knowledge Center
Your task: Log on to the Knowledge Center (http://knowledge.opentext.com/) and acquaint
yourself with its structure. Afterwards, utilize both the browse and search functions in
order to display the following documents:
01. The Release Notes of the current Archive Server version (by means of
browsing)
02. An answer to the question about the IP ports that Archive Server machines
use for communication
Appendix A-4 710-97

Exercise 3: Writing stored documents to WORM
Scenario: Writing stored documents to optical media is organized on an Archive Server as
periodic jobs. Using WORMs, there’s a separate job involved for copying the written
data from the original to the backup WORM.
Your task: Invoke the jobs for writing documents to WORM and backup WORM manually and
observe their logging output. After each finished job, also check the status of the
involved WORM volumes as displayed in the Archive Server Administration.
Normally, you would not run these jobs manually; instead, they are invoked periodically by the Archive
Server’s job scheduler.
Steps
1. Invoke WORM write job of logical archive A#
Watch its progress in the Messages pane
2. Review the status of the written WORM in the pool’s Volumes list
3. Invoke the Local_Backup job manually
4. Review the status of the WORM and its backup in the pool’s Volumes list

Exercise 4: Examine a document on storage media
Scenario: For each document stored in the Archive Server, you can query detailed status
information on a “technical” level. This is useful to understand what the Archive
Server is doing with the document, and it is often needed for troubleshooting if
problems with a certain document occur.
Your task: Use the archive command line tool dsClient to gather status information about the
sample document of exercise 1. Try to understand what information the query output
reveals.
Find out the actual storage path(s) of your document and visit the document in the
disk buffer on filesystem level (using the Windows Explorer). Compare what
dsClient tells about the document with what you actually find in the disk buffer.
Advanced task (optional): Add notes and/or annotations to the document and see
how the document’s state changes in dsClient’s status display and in the disk
buffer. Then invoke the WORM write job of your logical archive manually and once
more examine the document’s status.
You can repeat adding notes/annotations and writing to WORM a couple of times to
see how the Archive Server keeps track of these changes.
Steps
1. Open the sample document of exercise 1 in the Archive Viewer
2. Retrieve the document’s ID and copy it into the Windows clipboard
Use menu Document → Archive Information
3. Retrieve document status information with dsClient

• Use dsClient’s commands dinfo, cinfo, and volInfo
• Paste the document ID from the Windows clipboard by right-clicking into the command line
window
4. Open the Windows Explorer and navigate to the document’s storage location in the disk
buffer, as retrieved before
5. Open file ATTRIB.ATR in Wordpad and examine its contents
(Opening in Notepad is not useful; line breaks are not displayed correctly)
Appendix A-6 710-97

Exercise 5: Finalizing a WORM
Scenario: A WORM volume has been filled up with documents and shall now be finalized.
Your task: Finalize the first WORM volume assigned to logical archive A#, then review its
status in the media list of the WORM jukebox. Afterwards, take a measure to have
the corresponding WORM backup finalized, too; then review the status of the
backup in the jukebox’s media list.
During this proceeding, watch the filling rate of the WORM filesystem database.
Steps
1. Retrieve WORM filesystem filling rate
Use an appropriate cdadm command on the command line
2. Finalize the WORM volume

3. Review the volume status in the media list of the WORM jukebox
4. Retrieve WORM filesystem filling rate again
Compare with previous value
5. Invoke the Local_Backup job in order to finalize the backup WORM
6. Review the backup’s status in the media list of the WORM jukebox
7. Retrieve WORM filesystem filling rate again
Compare with previous values

Exercise 6: Create logical archive on Archive Server
Scenario: Your company decides to extend the use of your Archive Server. You are using
different types of media and different scenarios require several logical archives with
different settings.
Your task: Create and configure three new logical archives on your course machine:
• Create a logical archive named B# with IXW pool (WORM).
• Create a logical archive named D# with ISO pool (DVD).
• Create a logical archive named F# with FS pool (Single File on hard disk).
Take care of the following aspects:

• Do not create a new disk buffer for the pool; use the already existing one
instead.
• Enable no document options and no retention settings.
• Set HTTP security options so that signature authentication is not required;
all access types shall be “free”.
For testing your logical archives you need to store documents, run the write job
and verify if media is written. You can store documents using the dsClient.
Optionally, it is also possible to reconfigure your scanning client (Enterprise Scan)
so that newly scanned documents will be stored in the new logical archive. The
documents then can be stored and viewed as described in exercise 1 or 2.
• Writing on ISO pool requires minimum data amount of 1MB. Use the docWrite2 command as
described above to store large documents. (Don’t archive too much data either. Your training
system has limits.)
• Many of the integrated Open Text products require to define the new logical archive also in the
leading application. This configuration step is discussed in the product-specific Learning
Services administration courses.
Subtasks Steps
I Create and configure 1. Create logical archive
logical archive B#, D# and 2. Create and configure media pool
F# on the Archive Server
(repeat all steps for each For IXW pool, you should activate automatic initialization.
logical archive) For ISO pool, choose 1 MB as minimum required data amount.
For FS pool, if there is an empty hard disk partition available, you
need to create a hard disk partition first.
3. Make sure not to enable any Security, Settings or Retention options.
Do not use any of the processing options like encryption or
compression in this example.
4. Uncheck any HTTP security, such as Signature.
Appendix A-8 710-97

1. Create a directory c:\archive on your Archive Server.
II Store sample documents
on your logical archive 2. Put any document from your filesystem in it (i.e. a *.bmp from
c:\windows)
For ISO pool, you might need to choose one or several larger documents
to meet the 1 MB minimum requirement.
3. Go to dsClient
4. Use the command poolInfo to identify the Pool for the logical
archive you want to use.
5. Perform docWrite2 <LogicalArchive> c:\archive <Pool>
1. Go to the write job within the pool of your logical archive

III Run write job for your
logical archive and 2. Choose Job → Start
check that a partition has 2. See in the job log if your documents were written to media properly.
been written
3. Go to the pool in your logical archive and see if any Volumes have
been written.

Exercise 7: Create disk buffer
Scenario: As document retrievability requirements change in your company, it has become
necessary to create and configure a second disk buffer on the Archive Server. This
disk buffer shall retain documents for about two months after which it may drop them
without caching. Moreover, a space reserve of 20% should always be available for
new documents.
Your task: Create a new disk buffer on the Archive Server of your course machine and
configure it according to the requirements described above. Assign the disk buffer to
logical archive B#.
Afterwards, test your new arrangement by archiving a sample document into B# and
retrieving it again.
Advanced task (optional): Use dsClient to prove that the document is really
stored in the new disk buffer.
About step 1 (mentioned below): Within this exercise’s context (never for operating a production
Archive Server!), you may create a new directory in an existing partition instead and use this directory
in place of a partition.
Steps
1. Provide hard disk partition (on hardware and operating system level)
2. Create and configure disk buffer
3. Assign disk buffer to ISO or IXW pool of logical archive B#
4. “Scan”, store, and retrieve sample document
See exercise 1 or 2, respecively
Appendix A-10 710-97

Exercise 8: Store and examine a document in a BLOB
Scenario: Documents in BLOBs are managed differently by the DocumentService, which also
affects the work with document status information in dsClient.
Your task: Store a sample document in a BLOB (for this, you first have to enable the BLOBs
option for your logical archive). Afterwards, examine how and where the document is
stored — like you have done in exercise 5 —, but take into account that the
document is “buried” in a BLOB this time.
Steps
1. Activate the BLOBs processing option of logical archive A#
2. Store a sample document
Just repeat either exercise 1 or 2
3. Display the new sample document in the Archive Viewer and retrieve the document’s ID
4. Retrieve the document’s current storage location with dsClient

• Use dsClient’s commands dinfo, cinfo, and volInfo
• Apply dinfo to the reported BLOB in order to see where it is stored in the disk buffer
5. Visit the BLOB on filesystem level (using the Windows Explorer)

Exercise 9: Store and examine a single-instance archived document
Scenario: If single-instance archiving is used, documents are managed differently by the
DocumentService, which also affects the work with document status information in
dsClient.
Your task: Having activated single-instance archiving, store a sample document, then store the
same sample document a second time.
Afterwards, use dsClient to examine how and where the two documents are stored
— similarly to exercise 5. Use the dsClient output to prove that both documents are
in fact references to a single stored instance.
For technical reasons, this exercise uses scan documents as examples for single-instance archiving
(although you whould not really do this in practice). However, this does not work for FAX format
documents scanned with Enterprise Scan. Therefore, you will have to use the colored sample
documents provided in JPEG format; to do that, make sure you apply the image input directory
mentioned in exercise step 2 below.
Alternatively, you can also archive two identical documents using dsClient:
• Create a directory c:\archive on your Archive Server and put a random document from
your filesystem in it.
• Go to dsClient
• Use the command poolInfo to identify the Pool for the logical archive you want to use.
• Perform twice docWrite2 <LogicalArchive> c:\archive <Pool>
• Remember both DocIDs
Steps
1. Activate the single-instance processing option of logical archive A#
2. Store a sample document two times
Just repeat either exercise 1 or 2
Use file input path: \\<trainer_host>\scandocs\images
3. Display the new sample documents in the Archive Viewer — one after the other — and
retrieve their document’s IDs
4. Retrieve the documents’ true storage location(s) with dsClient

Use dsClient’s commands dinfo, cinfo, and volInfo
5. Visit the stored document instance on filesystem level (using the Windows Explorer)

Exercise 10: Retention Settings
Scenario: Experiment with retention settings for a logical archive.
Your task: Archive documents with different retention settings and verify with dinfo the
applied retention. Try if you can delete documents that have a retention setting in
dsClient.
Turn on compliance mode and try it again.
Once you turn on Compliance Mode, it cannot be turned off anymore. Choose your logical archive
for this exercise carefully.
Steps
1. On your logical archive, check that Default settings for Retention is set to No
retention.
Do not activate Compliance mode at this moment yet.
2. Store a sample document and check dinfo in dsClient
• Create a directory c:\archive on your Archive Server
• Put any document from your filesystem in it (i.e. a *.bmp from c:\windows)
• Go to dsClient
• Use the command poolInfo to identify the Pool for the logical archive you want to use.
• Perform docWrite2 <LogicalArchive> c:\archive <Pool>
3. Set retention period to 2 days

4. Store another sample document and check its document information.
See if the retention time is different.
5. Try to delete document with delete in dsClient.
If you have a leading application (i.e. SAP), you can also try to delete the document from the
leading application.
6. Turn on Compliance Mode for logical archive and test again.
Check again if you can delete a document now.

Exercise 11: Archive Server components
Scenario: As Archive Server administrator you should be familiar with the locations on the
server’s file system where Archive Server stores its data and configuration settings.
Locations that are not equal by default on all Archive Server installations can be
looked up at appropriate places within the system itself.
Your task: Find and note down the locations (directory paths and, where applicable, file names)
of the following Archive Server components on your course machine. (Please make
also a short note about where you have found this information.)
01. DocumentPipeline directory (if available)
02. ISO burn buffer and/or WORM filesystem database (depending on your
interest)
03. Read cache
04. Hard disk partition of the disk buffer used for logical archive A#
05. Oracle datafiles (one of them as example)
06. Oracle archivelog directory

Exercise 12: Check operating condition and restart Archive Server
cleanly
Scenario: The Archive Server comprises a number of processes running on the machine and
— partly — depending on each other. If some of these have terminated, the server
has to be restarted in an orderly way.
Your task: Check the running status of the Archive Server processes on the different process
layers. If the status is not okay (i.e. the database does not react or some spawner-
driven processes are terminated irregularly), stop and restart the processes in the
proper order. After this, check the status again to make sure everything is working
properly.
Steps
1. Check the process status (on Spawner, Tomcat and database layer)
2. Restart the processes in the proper order
3. Check the process status again

Exercise 13: Archive Server monitoring
Scenario: Monitoring the Archive Server for problems is one of the essential daily tasks of the
server adminstrator or operator.
Your task: Use the archive monitoring tools to check for possible problems on your Archive
Server. If problems are reported, note down the “problem subject” and try to decide
what kind of problem it is.
Steps
1. Examine the system status using the Monitor Web Client. It is available at
http://<ArchiveServer>:8080/w3monc
2. Check results of periodic jobs in the Archive Server Administration

Exercise 14: WORM operating
Scenario: Using WORMs as storage media requires a certain sequence of working steps to be
done regularly, as an essential element of Archive Server operating.
Your task: Do the steps of handling a WORM medium until it has reached its final state (read-
only, backed up, finalized). Do not forget to maintain the backup as well.
• To simplify this exercise, it is sufficient to consider one side of a WORM only
(as opposed to a “real-life” situation where a WORM is “finished” only as soon
as both sides have reached this state).
• As another element of “playing”, invoke the involved jobs for writing data to
WORM or backup WORM manually.
Do the steps in this order:
01. Initialize a WORM volume
02. Assign the WORM volume to the WORM pool of archive B#
03. Run the pool’s WORM write job
(Representing regular writing of documents to the WORM)
04. Run the WORM local backup job
05. Finalize the WORM volume
06. Finalize the WORM backup volume (how?)

Exercise 15: Volume migration
Scenario: While your Archive Server is currently equipped with a certain storage system, your
company has decided to use another.
The contents of all previously written volumes have to be migrated to new volumes
before the old storage system can be switched off and disconnected.
Another reason for migration can be that you want to move old optical media to new
ones because the original media has become old and you want to prevent data loss
due to age.
Your task: Migrate the documents of the DVD media to new media (i.e. WORM or DVD) so that
the old DVDs can be exported afterwards. This task comprises the following items:
• Preparing (configuring) the migration
• Enqueuing the DVDs for migration
• Checking the migration status
• Exporting old volume as soon as migration is finished (not part of this
exercise)
• Make sure that you write all your previous data from disk buffer to your old media first.
• If you migrate to WORM, attach them to the target pool and choose automatic WORM
initialization before doing the migration
• Normally, you would not run the involved jobs manually; instead, they are invoked periodically
by the Archive Server’s job scheduler.
Subtasks Steps
I Prepare volume migration 1. Create job for starting migration
Go to Jobs and create a job with the Migrate_Volumes command.
2. Create migration target pool
Use a New Storage Tier migration.
Check a document’s ID on old media using dinfo in dsClient. See

where it is stored.

II Do the migration 1. Enqueue (plan) the DVDs for migration
Use the VolMig Migrate Components on Volume command.
Afterwards, examine migration status in Utilities → VolMig
Status.
2. Start migration by running the migration job
Run the job you have created previously.
Afterwards, examine migration status in Utilities → VolMig
Status.
3. Run the media write job of the migration target pool
Afterwards, examine migration status in Utilities → VolMig Status
(nothing should have changed).
4. Run the migration job again
Afterwards, examine migration status in Utilities → VolMig Status
(at least one of the DVDs should be marked as finished)
Check the previous document ID again using dinfo in dsClient. Where
is the document stored now?

Exercise 16: Volume export and import
Scenario: Now that your Archive Server is running for several years, the first documents have
passed their retention period and may be removed from the system. This is done by
storage medium: You export a medium from the Archive Server as soon as all
documents stored on it have expired.
Your task: Export that storage medium of logical archive B# that carries the sample document
of exercise 7 from your Archive Server.
Afterwards, re-import the medium so that the document becomes available again.
Before, between, and after these actions, try to retrieve the document and query the
document’s status with dsClient in order to see the effects.
Steps
1. Retrieve the sample document of exercise 7 in the Archive Viewer
2. Find out the volume the document is stored on
• Using dsClient’s dinfo command
• Fetch the document ID from the Archive Viewer (see previous step),
menu Document → Archive Information
3. Export the volume from the storage database

Watch the progress in the Messages box
4. Query the document’s status with dsClient again

Compare to previous status information
5. Try to retrive the document in the Archive Viewer again
6. Import the volume into the storage database
Watch the progress in the Messages box
7. Query the document’s status with dsClient

Compare to previous status information
8. Retrive the document in the Archive Viewer again

Exercise 17: Check consistency of storage volume and database
Scenario: Assume you have had problems with the storage database of your Archive Server,
which have made necessary to recover the database from a backup. After the
recovery has been made, you should check — and, if necessary, repair — the
consistency between the database and the volume.
Your task: Check whether all documents stored on a certain volume are really known to the
storage database.
If inconsistencies are detected, repair them.
Finally, do the check again to make sure the inconsistencies have been solved
properly.
• Your trainer will tell you which volume to check.
• Keep in mind that re-importing previously deleted documents will not work on
Archive Server ≥ 9.6.
• A good way to test the repair option for partitions:
o Write a document to an Single File FS pool
o Make sure there is still a copy on Diskbuffer
o Manually delete the ATTRIB.ATR file.
Steps
1. Check whether all documents on the volume are known to the database
• Do not use the repair option yet
• Examine the result in the Messages box
2. If missing documents are detected: Do the check again, this time with repair option enabled
3. Do the check one more time
No inconsistencies should be reported any longer

Exercise 18: Remote Standby configuration and operating
Scenario: Your Archive Server shall be replicated remotely by a RemoteStandby server.
Reversely, your server shall keep replicates of the data stored on the other server.
Your task: Configure RemoteStandby replication for your logical archive B# as well as for your
disk buffer (created in exercise 8).
On the RemoteStandby server, equip the replicated items (disk buffer and pool) with
volumes as needed.
After these preparation steps, perform the remote replication by running the
corresponding job on the RemoteStandby server. Finally, check the result by
examining the status display for the replicated volume on both the original server
and the RemoteStandby server.
• Do this exercise in a team together with your classroom neighbour: One of you represents the
original side, the other one the replication side.
If you are interested and there is enough time, you may switch roles and do the steps again in
the opposite direction.
• Normally, you would not run the replication job manually; instead, it is invoked periodically by
the Archive Server’s job scheduler.
Subtasks Steps
I Configure remote 1. Globally enable remote replication on original server
replication 2. Make original and RemoteStandby server known to each other
Do not forget the Allow replication option on the original server
3. Configure replication of logical archive B#
Configure the archive’s pool as well
4. Configure replication of the disk buffer (created in exercise 8)
II Provide media replicates 1. Initialize replicate for Disk buffer Disk volume
• Maybe an already existing disk volume has to be renamed before
to avoid a naming conflict
• If available on the RemoteStandby classroom server, rather use an
existing, unused HD drive instead of creating a new one with the
Windows Disk Manager
2. Initialize WORM replicate(s)
Only if the replicated archive has got a WORM pool
III Perform the replication 1. Run the replication job on the RemoteStandby server
Watch its progress in the Messages box
2. Review the status of the volume replicates on the RemoteStandby
server
• Disk buffer
• WORM, CD, or DVD replicates
3. Review the volume replication status on the original server
• Disk buffer
• Replicated WORMs, CDs, or DVDs

Exercise 19: Scheduling periodic jobs
Scenario: A number of essential tasks of the Archive Server is executed as periodic jobs; the
job schedule is managed in the Archive Server Administration itself.
Since some of the tasks of jobs are quite resource-consuming, paying attention to a
“cooperative” scheduling is a precondition for smooth server operation.
Your task: Examine the job schedule on your Archive Server; find out whether jobs are
scheduled in a way that no resource conflicts are induced.
If you find that some resource-critical jobs are scheduled to run simultaneously,
improve the schedule, respecting reasonable recurrence periods for the different
jobs.
Wherever reasonable, also make use of job concatenation to improve your
scheduling concept.
Steps
1. Examine your Archive Server’s jobs table for resource-critical jobs
Which jobs fall into this category?
2. Examine and compare the schedules of the found critical jobs
• Are the jobs scheduled “cooperatively”?
• Does the scheduling need improvement?
3. If scheduling needs improvement: Work out a better scheduling concept
• Consider using job concatenation. Where is this reasonable?
• Do not forget to plan “job-free” periods for offline backups
4. Reconfigure the job scheduling according to your improved concept

Exercise 20: Audit Trails
Scenario: Retrieve Audit Information and clean up old Audit Trails.
Your task: Get Document History for a single document.
Export document and administrative audit info.
Schedule a job for purging old audit entries.
• Make sure that you perform this exercise with documents on a logical archive in Compliance
Mode.
• Keep in mind that Get Document History gives information also on existing documents, whereas
document audit info contains information on deleted documents. Due to Compliance Mode,
there might not be many documents in the document audit info.
Subtasks Steps
I Get Document History for 1. Pick a document in a logical archive with Compliance Mode.
Single Document Remember DocID.
2. Open your web browser and enter the URL (getDocumentHistory):
http://<ArchiveServer>:8080/archive?getDocumentHistory&contRe
p=<LogicalArchive>&docId=<DocID>&pVersion=0045
(replace ArchiveServer, LogicalArchive and DocId in URL
accordingly)
3. Delete/modify document (i.e.add/delete component).
Use command i.e. delete in dsClient.
2. Check getDocumentHistory again
There should be additional entries in the history.
1. Check existing audit files
II Access Audit Info with Look in directory <OT var>/audit/
exportAudit
2. Create audit file for documents
In command line window, perform exportAudit –S
3. Create audit file for administrative entries.
In command line window, perform exportAudit –A
4. Check existing audit files.
Look in directory <OT var>/audit/. There should be new audit files
created now.

III Purge Audit Data as Look in directory <OT var>/audit/
Scheduled Job
2. Configure Sweep Audit Data Job
Go to RCS → Configuration → Archive Server →
AS.ADMS.AUDITING.ADMS_AUDIT_MAX_RECORD_AGE and set time to
keep records to i.e. 1 day.
3. Run Audit Sweeper (SYS_CLEANUP_ADMAUDIT) job in archive
administration.
3. Create new audit files for administrative and document entries.
• Perform exportAudit –S
• Perform exportAudit –A
4. Verify results.
Look in directory <OT var>/audit/. Check the size & contents of the
new audit files. Only the administrative file should be affected.

IV Purge Audit Data with
Look in directory <OT var>/audit/
exportAudit
2. Purge existing audit data
• Perform exportAudit –S –x
• Perform exportAudit –A -x
3. Create new audit files for administrative and document entries.
• Perform exportAudit –S
• Perform exportAudit –A
4. Verify results.
Look in directory <OT var>/audit/. Check the size & contents of the
new audit files.

Exercise 21: Deletion Holds
Scenario: Due to business requirements, you want to ensure that no documents are deleted
on the archive server or a specific logical archive.
Your task: Turn on deletion hold globally on the archive server and alternatively block deletion
of documents on a logical results and verify the results.
Steps
1. Put a global deletion hold on your Archive Server.
Right-click Archive and Storage Services and select Configure Runlevel... and set
Maintenance Mode to Documents cannot be deleted, errors are returned.
2. Try to delete a document in dsClient and verify result.

Pick a document, remember its DocID and use the delete command.
3. Turn off global deletion hold.
Set Runlevel Configuration to No maintenance mode.
4. Choose the logical archive of the previous document and prevent document deletion.
Configure Archive Access on logical archive and set Document deletion to Causes
error.
5. Try to delete a document in dsClient and verify result.
Pick a document, remember its DocID and use the delete command.
6. Try to delete a document from another logical archive and verify result.

Exercise 22: Online backup of WORM filesystem database
Scenario: Assume you are obliged to operate the Archive Server in “7x24” mode, thus all
relevant data on the server has to be backed up online.
Your task: Perform an online backup of STORM’s WORM filesystem. Afterwards, visit the
directory where the backup files have been stored; examine how they correspond to
the original database files.
Steps
1. Invoke the Save_Storm_Files job manually
2. Find and note down the location of the WORM filesystem and the backup destination
directory in server.cfg file
3. Visit both directories and compare what you find there

Exercise 23: Add partition to disk buffer
Scenario: As the average rate of newly stored documents has grown over time, your disk
buffer has become too small for normal operation.
Your task: Enlarge the disk buffer — created in exercise 8 — by assigning a second hard disk
volume to it.
About step 1 (mentioned below): Within this exercise’s context (never for operating a production
Archive Server!), you may create a new directory in an existing disk volume instead and use this
directory in place of a disk volume.
Steps
1. Provide hard disk volume (on hardware and operating system level)
2. Make disk volume known to Archive Server
3. Attach new disk volume to Disk buffer

Exercise 24: Move DocumentPipeline directory
Scenario: As the average rate of documents processed by the DocumentPipeline, the hard
disk volume holding your DocumentPipeline directory has become too small for
normal operation.
Your task: Move the DocumentPipeline directory to a different location (i.e. to a larger disk
volume).
Doing this, take care that the current DocumentPipeline contents is retained and
further processed afterwards!
Within this exercise’s context (never for operating a production Archive Server!), you may create a new
directory in an existing hard disk volume (e.g. C:) instead of providing a truly new disk volume.
Depending on setup, a DocumentPipeline might be available either on Archive Server or i.e. an
Enterprise Scan client.
Steps
1. Find out the location of the DocumentPipeline directory
Look in <pipeline config root>/config/setup/COMMON.Setup
2. Create new directory in a different HD partition
See hint above
3. Alter DP directory configuration parameter to point to the new location
Do not restart the Archive Server yet to make the change effective
4. Shut down Archive Server processes
5. Move contents of old DP directory to new location
Pay attention to retain the directory structure underneath the configured directory!
6. Start Archive Server processes
Afterwards, check that all processes are running properly
7. Store a sample document via the DocumentPipeline
… to prove the DP is working properly again

Appendix B
Archive Server – Command Line Tools
Overview
0. General Remarks 3. dpctrl
1. dsClient 3.1. General
1.1. General 3.2. Loglevels
1.2. Volume-related actions – volInfo 3.3. Working with DS DocumentPipeline
[<volName1>[, <volName2> … 4. ixmonTest / ixmontst (Windows)
]] 5. cdadm
1.3. Document-related actions 5.1. Listings of jukeboxes and media
1.4. Statistics 5.2. Media handling
1.5. Loglevels 5.3. Loglevels
2. spawncmd 5.4. Miscellaneous
0. General Remarks
• All command line executables are located in <IXOS_ROOT>/bin which is normally included in the
command search path (on a Unix-based Archive Server, it may be necessary to source
/usr/ixos-archive/config/setup/profile before); they can therefore be called from any
directory on the Archive Server.
• Most arguments or commands that the tools understand must be specified respecting the given
upper-/lowercase spelling.
1. dsClient
• Command line front end to the DocumentService
• For document and media-related administration and troubleshooting tasks
• Detailed documentation in ESC:
1.1. General
Start dsClient and log on to a DocumentService:
dsClient <servername> <username> <password>
or
dsClient <servername> <username> (You will be prompted for the password. This
hides the password from the screen and from the
computer’s process list)
This will open dsClient’s internal command line shell. Is there a no password please type in "" for
the password, e. g. dsClient servername dsadmin "".
Get help about available commands:
help
Exit from dsClient:
end
Archive Server – Command Line Tools Appendix B-1

1.2. Volume-related actions – volInfo [<volName1>[, <volName2> … ]]
Display list of volume names:
volInfo
Display status information for a specific volume:
volInfo <volName>
Change percentage of space left free on a volume:
chgVolP <volName> <percent_value>
(Valid for WORMs and HD partitions)
Change a volume’s writable status:
chgVolS <volName> wrlock (set write-lock)
chgVolS <volName> zero (clear write-lock)
(Valid for UDO, WORM and HD partitions)
1.3. Document-related actions

Display status information for a document:
dinfo <docID>
Display status information for a document component:
cinfo <docID> <compName>
Cache a document:
cache <docID>
Retrieve a document:
docRead <docID>
The document is then written to a new local subdirectory named after the docID.
docRead <docID> <path>
The document is then written to the path, in case the path does not exist, he would be generated.
1.4. Statistics
Display statistics about media and cache hits:
stat RC read
Display statistics about media access:
stat RC volume (read access)
stat WC volume (write access)
Reset statistics:
stat RC readclear
stat RC volumeclear
stat WC volumeclear
Moreover, statistics are reset at each Archive Server restart.
1.5. Loglevels
Show current loglevel settings:
getLogLevel <component> <log_switch>
(where <component> is one of RC (read component) and WC (write component) and <log_switch>
is one of the log switch tags WRN, RES, UER, INF, DBG, and ENT)
Appendix B-2 710-97

Set loglevel dynamically:
setLogLevel <component> <log_switch> <value>
(where <component> is one of RC (read component) and WC (write component), <log_switch> is
one of the log switch tags WRN, RES, UER, INF, DBG, and ENT or the meta value ALL, and
<value> is one of 0 and 1)
2. spawncmd
• Command line frontend to the spawner service
• For starting, stopping, and querying the status of Archive Server processes
Query the status of spawner-controlled Archive Server processes:

spawncmd status
Stop / restart individual Archive Server processes:
spawncmd (start | stop) process_name
(Be careful: Not all Archive Server processes can be stopped and restarted in just any order! If in
doubt, it is better to do a stopall/startall instead.)
Re-queue deferred documents in Document Pipeline:
spawncmd start stockist
Stop / restart all spawner-controlled processes:
spawncmd (startall | stopall)
Stop all spawner-controlled processes + spawner itself:
spawncmd exit
3. dpctrl
• Command line frontend to the DocumentPipeline
• For monitoring and manipulating the DocumentPipeline
• Corresponds to the DocumentPipeline Info GUI
3.1. General
Get help about available commands:

dpctrl help
Display status of DocTools or DocTool queues:
dpctrl tools | queues
Get free space of document pipeline directory:
dpctrl fssize
Dis-/enable a DocTool:
dpctrl [ disable | enable ] doctool
Start or stop a DocTool (that is not enable or disable!):
dpctrl [ start | stop ] doctool
Stop the document pipeline (BUT: restart with spawncmd!):
dpctrl shutdown

3.2. Loglevels
Set new loglevel for document pipeliner dynamically:
dpctrl loglevel value
Set new loglevel for specific DocTool dynamically:
dpctrl msg <DocTool> setLogLevel <log_switch> <value>
(where <DocTool> is one of the DocTool names listed in the output of dpctrl tools, <log_switch> is
one of the log switch tags WRN, RES, UER, INF, DBG, and ENT, and <value> is one of on and off)
3.3. Working with DS DocumentPipeline

Work with internal DocumentPipeline of the DocumentService instead of “external” pipeline:
dpctrl –P 4025 ... (append commands and arguments as described above)
4. ixmonTest / ixmontst (Windows)

• Command line frontend to the Monitor Service
• For script-based Archive Server monitoring
• Equivalent to the Archive Server Monitor GUI
Display list of monitoring information:

ixmonTest walk <start_number> <end_number> (Unix)
ixmonTst walk <start_number> <end_number> (Windows)
5. cdadm
• Command line frontend to STORM
• For script-based media and jukebox management
• Corresponds to Devices section in Archive Server Administration
• Detailed documentation in KC:
5.1. Listings of jukeboxes and media
Display list of jukebox devices:

cdadm survey -d +d
Display list of disk volumes with slot numbers:
cdadm survey -v +so
cdadm survey -v +so d=<jukebox_name> (list contents of specified jukebox only)
Display list of disk volumes with date of last access (time displayed as number of seconds since the Unix
epoch):
cdadm survey -v +oL
Appendix B-4 710-97

5.2. Media handling
Open jukebox mailslot for inserting a disk:
cdadm insert <jukebox_name>
(Useful if no graphical display available near the jukebox)
Eject a disk:
cdadm remove <jukebox_name> <slot_number>
(Useful if no graphical display available near the jukebox)
5.3. Loglevels
Show current loglevel settings:
cdadm getpar loglev *
Set loglevel dynamically for a STORM component:
cdadm setpar loglev <log_level> <component>
(where:
<log_level> is a numerical value between from 0 to 4, and
<component> is one of the component names listed in the output of cdadm getpar loglev *)
5.4. Miscellaneous
Display size and filling rate of WORM filesystem database:
cdadm read fs%worm%cache
Test STORM operation:
cdadm null

Appendix B-6 710-97
Appendix C
Glossary
This is a list of the most common Archive Server related terminology.
ADMC
See: Archive Administration (ADMC)
Administration Server (ADMS)
Process (running on the archive server machine) which maintains archive system configuration data,
such as logical archives, pools, jobs, internal users.
ADMS
See: Administration Server (ADMS)
Annotation
The set of all graphical additions assigned to individual pages of an archived document (e.g.
coloured marking). These annotations can be removed again. They simulate hand-written
comments on paper documents. There are two groups of annotations: simple annotations (lines,
arrows, highlighting etc.) and OLE annotations (documents or parts of documents which can be
copied from other applications via the clipboard).
See also: Notes.
Archive Administration (ADMC)

Administration tool for setup and maintenance of servers, logical archives, devices, pools, disk
buffers, archive modes and security settings. Frontend interface for customizing and
administering the Archive Server.
Archive ID
Unique name of the logical archive.
Archive mode
Specifies the different scenarios for the scan client (such as late archiving with barcode,
preindexing).
Archive Web Monitor

Web based administration tool for monitoring the state of the processes, storage areas, Document
Pipeline and database space of the archive server.
ArchiveLink
The interface between SAP system and the archive system.
Glossary Appendix C-1

Buffer
Also known as “disk buffer”. It is an area on hard disk where archived documents are
temporarily stored until they are written to the the final storage media.
Burn buffer
A special burn buffer is required for ISO and IFS poosl in addition to a disk buffer. The burn
buffer is required to physically write an ISO image. When the specified amount of data has
accumulated in the disk buffer, the data is prepared and transferred to the burn buffer in the
special format of an ISO image. From the burn buffer, the image is transferred to the storage
medium in a single, continuous, uninterruptible process referred to “burning” an ISO image. The
burn buffer is transparent for the administration.
Cache
Memory area which buffers frequently accessed documents. The archive server stores frequently
accessed documents in a hard disk partition called the Document Service cache. The client stores
frequently accessed documents in the local cache on the hard disk of the client.
Cache Server
Separate machine, on which documents are stored temporarily. That way the network traffic in
WAN will be reduced.
Device
Short term for storage device in the Archive Server environment. A device is a physical unit that
contains at least storage media, but can also contain additional software and/or hardware to
manage the storage media. Devices are:
• local hard disks
• jukeboxes for optical media
• virtual jukeboxes for storage systems
• storage systems as a whole
Digital Signature
Digital signature means an electronic signature based upon cryptographic methods of originator
authentication, computed by using a set of rules and a set of parameters such that the identity of
the signer and the integrity of the data can be verified. (21 CFR Part 11)
Disk buffer
See: Buffer
DocID
See: Document ID (DocID)
DocTools
Programs that perform single, discrete actions on the documents within a Document Pipeline.
Appendix C-2 710-97

Document ID (DocID)
Unique string assigned to each document with which the archive system can identify it and trace
its location.
Document Pipeline (DP)

Mechanism that controls the transfer of documents to the Document Service at a high security
level.
Document Pipeline Info

Graphical user interface for monitoring the Document Pipeline.
Document Service (DS)
The kernel of the archive system. It receives and processes documents to be archived and provides them
at the client’s request and controls writing processes to storage media.
It consists of a read component (RC) and a write component (WC) which archives documents.
DP
See: Document Pipeline (DP)
DPDIR
The directory in which the documents are stored that are being currently processed by a
document pipeline.
DS
See: Document Service (DS)
Enterprise Scan
Workstation for high volume scanning on which the Enterprise Scan client is installed and to
which a scanner is connected. Incoming documents are scanned here and then transferred to the
Archive Server.
Hard disk partition

Used as an archive medium, it supports incremental writing as well as deletion of documents
with a strictly limited lifetime, such as paperwork of applicants not taken on by a company. Hard
disk partitions must be created and assigned a mount path on the operating system level before
they can be referred to in the Archive Administration.
Hot Standby
High-availability Archive Server setup, comprising two identical Archive Servers tightly
connected to each other and holding the same data. Whenever the first server becomes out of
order, the second one immediately takes over, thus enabling (nearly) uninterrupted archive
system operation.

ISO image
An ISO image is a container file containing documents and their file system structure according
to ISO 9660. It is written at once and fills one partition.
Job
A job is an administrative task that you schedule in the Archive Administration to run
automatically at regular intervals. It has a unique name and starts command which executes
along with any argument required by the command.
Known server
A known server is an Archive Server whose archives and disk buffers are known to another
Archive Server. Making servers known to each other provides access to all documents archived
in all known servers. Read-write access is provided to other known servers. Read-only access is
provided to replicate archives. When a request is made to view a document that is archived on
another server and the server is known, the inquired Archive Server is capable of displaying the
requested document.
Livelink Archive Windows Viewer

See: Windows Viewer
Livelink ECM - Archive Administration

See: Archive Administration (ADMC)
Livelink ECM - Archive Web Monitor

See: Archive Web Monitor
Livelink ECM - Document Pipeline Info

See: Document Pipeline Info
Livelink Enterprise Scan

See: Enterprise Scan
Log file
Files generated by the different components of the Archive Server to report on their operations
providing diagnostic information.
Log level
Adjustable diagnostic level of detail on which the log files are generated.
Logical archive
Logical area on the Archive Server in which documents are stored. The Archive Server may
contain many logical archives. Each logical archive may be configured to represent a different
archiving strategy appropriate to the types of documents archived exclusively there. An archive
Appendix C-4 710-97

can consist of one or more pools. Each pool is assigned its own exclusive set of partitions which
make up the actual storage capacity of that archive.
Media
Short term for “long term storage media” in the Archive Server environment. A media is a
physical object: optical storage media (CD, DVD, WORM, UDO), hard disks and hard disk
storage systems with or without WORM feature. Optical storage media are single-sided or
double-sided. Each side of an optical media contains a partition.
Monitor Server (MONS)

Obtains status information about archives, pools, hard disk and database space on the archive
server. MONS is the configuration parameter name for the Monitor Server.
MONS
See: Monitor Server (MONS)
Notes
The list of all notes (textual additions) assigned to a document. An individual item of this list
should be designated as “note”. A note is a text that is stored together with the document. This
text has the same function as a note clipped to a paper document.
Partition
A partition is a memory area of a storage media that contains documents. Depending on the
device type, a device can contain many partitions (e.g. real and virtual jukeboxes), or is treated
as one partition (e.g. storage systems w/o virtual jukeboxes). Partitions are attached - or better,
assigned or linked - logically to pools.
Pool
A pool is a logical unit, a set of partitions of the same type that are written in the same way,
using the same storage concept. Pools are assigned to logical archives.
RC
See: Read Component (RC)
Read Component (RC)

Part of the Document Service that provides documents by reading them from the archive.
Remote Standby
Archive Server setup scenario including two (ore more) associated Archive Servers. Archived
data is replicated periodically from one server to the other in order to increase security against
data loss. Moreover, network load due to document display actions can be reduced since
replicated data can be accessed directly on the replication server.

Replication
Refers to the duplication of an archive or buffer resident on an original server on a remote
standby server. Replication is enabled when you add a known server to the connected server and
indicate that replication is to be allowed. That means, the known server is permitted to pull data
from the original server for the purpose of replication.
Servtab files
Configuration files of the spawner which specify which processes to start.
Slot
In physical jukeboxes with optical media, a slot is a socket inside the jukebox where the media
are located. In virtual jukeboxes of storage systems, a slot is virtually assigned to a partition.
Spawner
Service program which starts and terminates the processes of the archive system.
Storage Manager
Component that controls jukeboxes and manages storage subsystems.
Tablespace
Storage space in the database. If there is not sufficient free storage space available, no further
archiving is possible.
Timestamp Server
A timestamp server signs documents by adding the time and signing the cryptographic checksum
of the document. To ensure evidence of documents, use an external timestamp server like
Timeproof or AuthentiDate. The IXOS Timestamp Server is a software that generates
timestamps.
Timestamp Server Administration

Configuration tool for the IXOS Timestamp Server.
Volume
Volume is a technical collective term with different meaning in STORM and Document Service
(DS). A DS volume is a virtual container of partitions with identical documents (after the
complete backup is written). A STORM volume is a virtual container of all identical copies of a
partition. For ISO partitions, there is no difference between DS and STORM volumes. Regarding
WORM (IXW) partitions, the STORM differenciates between original and backup, they are
different volumes, while DS considers original and backup together as one volume.
WC
See: Write Component (WC)
Appendix C-6 710-97

Windows Viewer
Component for displaying, occasional scanning with Twain scanners and archiving documents.
The Windows Viewer can attach annotations and notes to the documents.
WORM
WORM means Write Once Read Multiple. An optical WORM disk has two partitions. A
WORM disk supports incremental writing. On storage systems, a WORM flag is set to prevent
changes in documents. UDO media are handled like optical WORMs.
Write Component (WC)

Component of the Document Service carries out all possible modifications. It is used to archive
incoming documents (store them in the buffer), modify and delete existing documents, set,
modify, and delete attributes, and manage pools and volumes.
Write job
Scheduled administrative task which regularly writes the documents stored in a disk buffer to
appropriate storage media.

710-97 - Archive Server 9.7.1 Administration

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

710-97 - Archive Server 9.7.1 Administration

Uploaded by

Copyright:

Available Formats

Archive Server 9.7.

Learning Services course 710-97

Copyright © 2009 Open Text Software GmbH

2 Archiving with Open Text

3 Resources for Archive Server Administrators

4 Document Processing by the Archive Server

Table of Contents 0-3

5 Document Structure on Storage Media

6 IXW File system - WORM File system

7 Configuring Logical Archives

8 Disk Buffer Configuration

9 Document Processing Options

10 Document Lifecycle Management Overview

Table of Contents 0-5

13 Archive Server Startup and Shutdown

14 Archive Server Monitoring

17 Export and Import of Storage Media

18 Consistency Checks for Storage Media and Database

Table of Contents 0-7

19 Expanded Archive Server Installations

20 Remote Standby Configuration and Operating

21 Setting up an Administrator Workstation

23 Configuring Audit Trails

24 Backing up the Archive Server

25 Hard Disk Resource Maintenance

Table of Contents 0-9

26 Statistics and Accounting Information

27 Logfiles and Loglevels

28 Summary of troubleshooting tasks on Archive Server

Appendix A Exercise Worksheets

Appendix B Archive Server – Command Line Tools

Table of Contents 0-11

Course Objectives and Contents 1-1

Gain a basic understanding of the Archive Server

Be able to administer an Archive Server efficiently and reliably

Course Objectives and Contents • Slide 2

Course Objectives and Contents • Slide 3

Course Objectives and Contents 1-3

3 days Storage Systems

Special Archive Server

Archiving with Open Text 2-1

Archiving: Fundamental properties

Archiving with Open Text • Slide 2

Certain business scenarios require that documents & data ...

can be retrieved as needed

For a scanned document:

Archiving with Open Text • Slide 3

Archiving with Open Text 2-3

Storage Resource Handling

Archiving with Open Text • Slide 4

CAS storage systems (i. e. EMC Centera)

SAN/NAS storage systems (i. e. NetApp, HDS, STK …)

Hard disk partitions or HSM storage systems

Jukeboxes with Optical media (i. e. DVD, WORM, UDO)

Archiving with Open Text • Slide 5

About the media type abbreviations:

Archiving with Open Text 2-5

Local Buffered Write (secure & reliable through Disk Buffer)

Retention Periods Retention Periods

HP FSE NetApp HP FSE NetApp filer

IBM System Storage IBM System Storage

Sun NAS53X0 Sun NAS53X0

HDS HCAP HDS HCAP