Salsa 8 Backup And-Restore

How to Backup and Restore Overall
Salsa Solution
www.ipanematech.com | Beyond the Network…
Customer Care
13/03/2014
TN-0100200-14_Salsa_General_Backup_and Restore
Revision history
Version Date Changes / Comments
1.0 31/03/2014 Initial version
Compatibility
System ip|boss ip|reporter ip|agent ip|reporter web ip|export
Version >7.1 >7.1 >7.1 - >7.1 -
Revision All all all - - -
Infovista
4.3 4.3 4.3 4.3
release
OS Windows 2008 R2 and Linux RHEL > 5.6
Prerequisite
Technical Title
Note
www.ipanematech.com 2
TABLE OF CONTENTS
1. Objective ........................................................................................................................ 4
1.1. Scope ...................................................................................................................... 4
2. Backup ........................................................................................................................... 5
2.1. Salsa 7 .................................................................................................................... 5
2.1.1. License file ....................................................................................................... 5
2.1.2. ip|boss.............................................................................................................. 5
2.1.3. ip|uniboss ......................................................................................................... 7
2.1.4. Dashboard ....................................................................................................... 9
2.1.5. Salsa Weberver...............................................................................................10
2.2. Salsa 8 ...................................................................................................................10
2.2.1. Backup summary ............................................................................................11
2.3. Reporting ...............................................................................................................12
2.3.1. IP|Reporter Server (VF0 and VF4 mode) ........................................................12
2.3.2. IP|Reporter LoadBalancer (VF4 mode only) ....................................................22
2.4. Backup Summary ...................................................................................................34
3. Restore .........................................................................................................................35
3.1. Salsa ......................................................................................................................35
3.1.1. Restore procedure can be differentiated in two categories: .............................35
3.1.2. Partial Restore ................................................................................................35
3.1.3. Full restore ......................................................................................................36
3.1.4. IP|Reporter Server (VF0 and VF4 mode) ........................................................38
3.1.5. IP|Reporter LoadBalancer (VF4 mode only) ....................................................39
1. Objective
The purpose of this document is to give the procedures to Backup and Restore the whole
Salsa Solution (IP|Boss, Dashboard, Reporting).
Backups are necessary for a Disaster and Recovery Plan (DRP) as well as standard
maintenance and operations while trying to recover from a misconfiguration and or loss of
configuration.
1.1. Scope
The scope of this document only covers the following salsa components:
License file
ip|boss
Server configuration
Domains configuration
ip|uniboss
Server configuration
LDAP authentication service
Web applications
Dashboard
Salsa webserver
Salsa V8
IP|reporter LoadBalancer (VistaMart)
IP| Reporter Server
Cockpit configuration
Local configuration
2. Backup
2.1. Salsa 7
2.1.1. License file

License file can’t be backed up from the Salsa system it should be stored on a secured
location once the license is provided by mail by Ipanema technical support team.
2.1.2. ip|boss
2.1.2.1. Installation path

Installation path depends on the upgrade path and operating system.
~/salsa/ipboss
2.1.2.2. Initial backup

DRP procedure implies the server to be rebuilt from scratch, operating system and Salsa
environment installed. Upon first time installation (or upgrade), here are the information that
should be backed up.
Domain configuration files
No domains to back up
Uniboss domains configuration files
Following files needs to be saved:

~/ipboss/server/domains/uni_boss/config/__active__.ipmuniconf
~/ipboss/server/domains/uni_boss/conf/platform/license.ipmsys
General server configuration files
Additionally, these files also need to be backed up on a regular basis:

~/ipboss/server/conf/ipm_domains.conf
~/ipboss/server/conf/ipboss.conf
~/ipboss/server/conf/reports_desc.ipmsys
2.1.2.3. Maintenance and exploitation backup

Before performing any file backup for a domain the pending modification should be saved. In
ip|boss’s GUI the Update icon on the upper left should not be blinking.
On a daily basis, you need only to save the following files:

~/ipboss/server/domains/<domain>/conf/license.ipmsys
~/ipboss/server/domains/<domain>/config/__active__.ipmconf
On a multi domain platform these files should be copied for each domains listed in the
~/ipboss/server/domains/ location.
In addition following files needs to be saved from the

~/ipboss/server/domains/uni_boss directory:
General server configuration files
There is no need for additional file backup.
2.1.2.4. DRP backup

As well as the initial backup and the maintenance backup, the additional configuration that
needs to be backed up for DRP procedure are:
Domain configuration files should have been already saved on a daily basis, no additional
files to back up at this stage.
Following files needs to be saved from the ~/ipboss/server/domains/uni_boss

directory:
2.1.3. ip|uniboss

Installation path depends on the upgrade path and operating system.
~/salsa/uniboss
IP|uniboss service is composed of:
ApacheDS : LDAP dictionary storing users’s authentication and accounting information.
ip|uniboss server : Managing the domains, ISUs, users
Web server : Web application for the Salsa web portal.

environment installed. Upon first time installation (or upgrade) here are information that
ApacheDS configuration files
No files to back up here.

ip|uniboss server configuration files
The only file that should be backed up is the license file provided by Ipanema support.
Web server files
There is no file to backup up upon first installation.

Before performing any file backup for a domain the pending modification should be saved. In
ip|uniboss’s GUI the Update icon on the upper left should not be blinking.
LDAP directory should be saved on a daily basis, following directory must be backed up:
~/apacheDS/instances.
Domains configuration should be saved on a daily basis, following directory must be backed
up: ~/server/conf
Web server files
There is no file to backup at this stage.
2.1.3.4. DRP backup

As well as the initial backup and the maintenance backup, the additional configuration that
needs to be backed up for DRP procedure are:
As the LDAP directory should be saved on a daily basis there is no need to add extra
backup.
As the Domains configuration should be saved on a daily basis there is no need to add extra
backup.
Web server files
In some occasion there can be some specific tuning for the Web Apps provided by Ipanema.
If there is any specific tuning of the web apps the tuned web apps should be backed up.
Otherwise there is no need to backup any file. Web apps can be found in the following
directory: ~/web_server/webapps.
Please refer to Ipanema support for a tuning, backup/restore procedure for web apps.
2.1.4. Dashboard

Ipanema’s Dashboard is a web app part of the IP|Boss component.
It is stored in ~ /ipboss/server/.

Upon first time installation (or upgrade) here are information that should be backed up.
Dashboard configuration files
After first installation a zip file called data.zip located in ~/ipboss/server/postgresql/ contains
the initial configuration.
The database configuration files can also be backup:
~/ipboss/server/postgresql/data.zip
~/ipboss/server/pgbouncer/conf/

Real time information database is used to store for all domains 3 hour historical information
thus there is no need to perform daily backups.
2.1.4.4. DRP backup

In some occasion there can be some specific tuning for the dashboard provided by Ipanema.
If there is any specific tuning done it should be backup on a regular basis. Otherwise there is
no need to backup any file.
~/ipboss/server/pgbouncer/conf
~/ipboss/server/postgresql/data/ipm_database_users.txt
~/ipboss/server/postgresql/data/ipm_pg_bouncer.ini
~/ipboss/server/postgresql/data/postgresql.conf
~/ipboss/server/postgresql/data/postmaster.opts
2.1.5. Salsa Weberver

Salsa web server is stored in ~/apache/

environment installed. Upon first time installation (or upgrade) here are information that
There is no file to backup up upon first installation.

There is no file to backup at this stage.
2.1.5.4. DRP backup

In some occasion there can be some specific tuning for the Salsa Webserver provided by
Ipanema. If there is any specific tuning (Certificate/Customization of the Portal…) done it
should be backed up. Otherwise there is no need to backup any file.
~/apache/conf/
2.2. Salsa 8
Since Salsa Version 8, a backup script is available and is doing all the previous salsa
components files backup and some additional.
This script is located in ~/salsa/tools
You can launch this script for initial backup and Maintenance or exploitation backup, and
schedule a task (Task scheduler or Cron job) so that it can be launched on a regular basis.
It will create a zip file and the path of this Zip File has to be outside the ~/salsa directory
For a multi-part installation, the tasks have to be scheduled at the same exact same
time.
The command to launch is
~/salsa/tools/backup –backupFile <Path to backup result zip file>
2.2.1. Backup summary

The following table summarize the file to be backed up and the purpose of the backup.
Initial Operation DRP

Files
backup backup backup
~/ipboss/server/domains/uni_boss/config/__active__.ipmuniconf X X
~/ipboss/server/domains/uni_boss/conf/platform/license.ipmsys X
~/ipboss/server/pgbouncer/conf/ X X
~/ipboss/server/postgresql/data.zip X
~/ipboss/server/conf/ipm_domains.conf X
~/ipboss/server/conf/ipboss.conf X
~/ipboss/server/conf/reports_desc.ipmsys X
~/ipboss/server/domains/<domain>/conf/license.ipmsys X
~/ipboss/server/domains/<domain>/config/__active__.ipmconf X
~/ipboss/server/domains/ X X
~/ipboss/server/postgresql/data/ipm_database_users.txt X
~/ipboss/server/postgresql/data/ipm_pg_bouncer.ini X
~/ipboss/server/postgresql/data/postgresql.conf X
~/ipboss/server/postgresql/data/postmaster.opts X
~/uniboss/apacheDS/instances X
~/uniboss/server/conf X
~/uniboss/web_server/webapps X*
~/apache/conf/ X X*
Backupfile.zip X** X**
X* Backups only needed if specific tuning is made.

X** Salsa V8
2.3. Reporting
The reporting part backups consist in the 2 Databases:

Oracle database for the VistaMart LoadBalancer (VF4 mode only)
Objectstore databases for the reporter servers (1 per reporting instance)
2.3.1. IP|Reporter Server (VF0 and VF4 mode)

We will describe the tools available for each platform and how to use them:
Point-in-time copy (snapshots)
osbackup tool
Point-in-time copy is the preferred method and should be used if supported by your
environment.
In large deployments (multiple ip|reporter servers) and when using ip|reporter in VF4 mode,
backups should be managed using VistaCockpit.
We will see both ways hereafter.
2.3.1.1. General Recommendations

Backups should be stored on separate drives than the ones used for InfoVista databases
or the ObjectStore transaction log.
Backup files created using the VistaCockpit scheduling should then be backed-up on
external systems.
Backups should not be scheduled during the InfoVista data aggregations carried out at
midnight (we recommend planning backups around 3-4am).
The sizing of the backup storage should be chosen according to your backup policy.
We suppose that the maximum size that 1 instance database can reach is 50GB.
The backup process compresses the databases up to 75%.
According to the number of instances an InfoVista Server can handle, we can estimate the
maximum size of a full server backup.
The total backup files for 1 Infovista server according to the OS.
Linux/Solaris (8 instances) Windows (4 instances)
100GB/day 63GB/day
2.3.1.2. OSBackup tool (InfoVista 4.2, InfoVista 4.3)
2.3.1.2.1. Description
The Osbackup tool of Infovista can be used to perform a backup of the database on window
2008, Solaris (8, 9, 10) and Linux RHEL platform.
Ipanema highly recommend using Point-in-time copy for backups if supported in your
environment, OSBackup has a notable impact on service performance.
The backup can be done online (you don't need to stop the InfoVista services).
To backup the database, we suggest the following batch file that you should execute by the
Windows Task scheduler every day at 03:00am.
Create a dedicated directory (if possible on a separate disk).
Check the result regularly.
move /Y ipm_backup.bck ipm_backup.old
osbackup -f ipm_backup.bck "C:\Program Files\InfoVista\Essentials\data\manager.db"
"C:\Program Files\InfoVista\Essentials\data\collector.db"
Modify the path of manager.db and collector.db according to your installation.

This script allows having a copy of both the database of the last two days.
When done, you should backup these files on a separate media.
2.3.1.2.2. Remarks
Depending on the size of the collector database, "osbackup" task could be long and impact
InfoVista service by:
Outages in reports for both cases,
Reports are not available or very long before being displayed.
2.3.1.3. Point-in-time copy technology (snapshots)
2.3.1.3.1. Compatibility
Point-in-time copy (snapshot based) is possible in the following environments:
Solaris 10/sparc with UFS filesystem (uses Oracle’s fssnap tool)
Linux RHEL 5 or higher with LVM (uses LVM snapshots)
Windows 2008 in 64 bits mode does not support this method for backups
2.3.1.3.2. Overview
The implementation of the backup tool on UNIX requires an application which InfoVista
provides called ‘IVBackup’, which automates the backup process.
This application supports snapshots performed by fssnap (Solaris) on the UFS file system,
flashsnap (Veritas) on VxFS file system and lvcreate on Linux LVM partitions. You have to
run the application locally on the machine on which InfoVista is running
IVBackup tool automatically performs the following actions:
Server checkpoint of the IVServer instance
Perform a snapshot of the manager and collector databases
The identification of the snapshot tool (Solaris UFS or Veritas VxFS) is based on the
database path.
With Solaris UFS or Linux LVM filesystems; IVBackup creates the snapshot with the
provided <backingstore> (<backingstore>/ivbackup.<pid>).
On Veritas file system, IVBackup creates the snapshot with a default checkpoint name
(ivbackup.checkpoint.<pid>).
Release IVServer instance checkpointed

Mount the snapshot partition
If the mount point does not exist, IVBackup fails.
If this option is not provided, IVBackup temporarily creates its own mount point. It is
removed after the tar file is created
Tar the snapshot databases in one file
If requested compact the tar file using gzip and copy it to the requested location
Unmount the snapshot partition
Delete the snapshot
2.3.1.3.3. Usage
ivbackup [-i instance] [-u username] [-p password] [-b backingstore]
[-m mountpoint] [-t timeout] [-v] [-gzip] [-block blocksize] -o
backup
Connection:
-i instance: instance identification (default "")
Is the identifier of the InfoVista Server instance you wish to backup. It can be identified
by name (i.e.: iv1) or manager:collector:browser endpoint ports (10000:10001:10002)
-u username: username (default administrator)
InfoVista login (with administration privileges) to perform database checkpoint

-p password: password (default "")
Password of the user given above
Options:
-b backingstore: ufs backing store path (default "<backup
path>/ivbackup.<pid>")
This option is only necessary when InfoVista databases are stored on a UFS file
system. The partition for which the backingstore path is provided should have enough
free space to store a copy of the databases.
-block blocksize (default: 2M, unit: multiple of 512 bytes, min: 512 bytes, max: 64
megabytes)
This option is used to specify the chunksize. The chunksize is important for
performance. The default value should be efficient in most cases. If the specified
block size is smaller than 32k, the snapshot is created with 32k.
-m mountpoint: snapshot/checkpoint mount point (default "<backup
path>/ivbackup.mnt.<pid>")
This is the mount point used to mount the partition on which the snapshot is stored. If
this one does not exist, IVBackup fails. If this option is not set, IVBackup creates a
temporary mount point and when releasing the checkpoint, the mount point is
removed.
-t timeout: checkpoint timeout (default 3600s)
The database checkpoint is release right after the snapshot (a few seconds) this
timeout is only reached when an issue is encountered.
-v: verbose mode
-gzip: gzip backup file (requires gzip)
To use this option, gzip should be available in /usr/bin directory. If not, IVBackup fails.
-o backup: path of target tar file containing both Manager and Collector databases
Full path of target tar archive containing both Manager and Collector databases
Note: When using the backup tool, bear in mind the following points:
If IVBackup is interrupted (e.g. control-C), any on-going database checkpoint is
automatically released and any existing snapshot, backing store and mount point are also
removed.
Timeout must be greater than 15 seconds, in order to let enough time to perform the
snapshot.
The backingstore must be located outside the file system where the databases are stored.
If not, you will get a fssnap error: snapshot error: Invalid backing file path.
When using the -gzip option, IVBackup checks if /usr/bin/gzip is present. If not, IVBackup
aborts.
IVbackup emits a warning if destination file system is mounted with forcedirectio (Solaris)
To obtain the best possible performances, it is recommended to separate the databases

from the snapshot partition on different disks and even different disk controllers.
2.3.1.3.4. Example
You can back up InfoVista databases for IV Server instance"iv1":
ivbackup -i iv1 -u administrator -p "" -v -gzip -o
/bkp/IV1Backup10252004
2.3.1.4. VistaCockpit Backup Configuration (Windows, Linux, Solaris)

The advantage of using VistaCockpit Management Console to configure the Backup tasks is
that it will use by default the Point-in-time copy, and if not available use OSbackup tool.
The backup could be stored locally or directly on an external Network Drive.
2.3.1.4.1. Configuration
You first need to login the VistaCockpit management console using administrator credentials.
Once connected, select the task tab and right-click on the “Workflows on schedule” to select
the “New Workflow on schedule” option.
Create the Backup task
The new workflow should now appear in the left part of the window. We now need to set:
What we want to do, and when we want to do it.
Choose the schedule options

The scheduler interface is relatively explicit.
If you wish to keep several versions of the daily backups, you may wish to create more than
one backup workflow as not to overwrite the backup file every day. An initial workflow
scheduled on Sundays, Tuesdays, Thursdays and Fridays and a second one the rest of the
week for example.
Once the workflow schedule is defined, select the ‘‘Tasks’’ tab to define the actions to be
carried out.
Create the Backup Task
After choosing a name for the task, clicking in the “Command” field will open a list of preset
tasks.
Select ‘‘Backup and compress Manager and Collector databases’’ from the IV Server branch.
Some specific environments may require not compressing the backups (compressed NTFS
file systems for example).
Once the Command has been selected, choose the Target (IVServers)
A single task can backup multiple server and multiple instances. You may also create
multiple tasks for each of the servers/instances. Using the “Predecessors” field, you will be
able to set the order in which the tasks will be ran.
Note that if there are several instances among a server group spread on several IP|Reporter
servers, a separate task has to be launched.
For example, if you have iv1 on server1 and iv1 on server 2, the backup task will try to do in
parallel 2 backups of iv1 instance and it will fail.
The last step that needs to be done is setting the precise backup command that will be ran
on the servers.
Select the “Parameters” tab in the lower right part of the window. Two fields need to be filled:
Backup Directory: This is the directory name, local to the InfoVista server, where the
backup file will be stored.
Backup File: This is the filename that will be used for the backup files. VistaCockpit provides
some variable substitutions: $(target:Jmx.Info.InstanceName) InfoVista instance
name; $(Date|yyyy_MM_dd)  current date.
In our example, the generated backup file will be the following:
c:\InfoVista\backups\backup_all_iv1_2013_10_31
Important: You need to design a naming convention according to the chosen schedule:
The default backup filename suggested by VistaCockpit will create a new backup file every
day: This will fill up the disk
Choosing a name that does not contain the date will overwrite the older backup each time: In
the event of a server failure while the backup is running, you may not have any valid data to
restore from.
2.3.1.4.2. Configure task flow to Backup on an external Network Drive

This requires configuring 3 tasks for the Scheduled Workflow:
Mount_Drive Task: task that will launch the script to mount the network share from the
IP|reporter server (The script has to be located on the IP|reporter server)
Backup Task
Umount_Drive Task: task that will launch the script to unmount the network share from the
IP|reporter server (The script has to be located on the IP|reporter server)
Mount_drive Task:
Create the new task and select the command to launch (Execute a script).
Select the Target (IP|reporter server)
In parameter, give the absolute path of the mount script in “Program” field
In our example, the script is mount.bat and is located in C:\Users\Administrator\Desktop on
the IP|Reporter server “Salsa71”.
Backup task
The backup task is the same as we describe previously except that we should add a
“Predecessor” task Mount_drive.
The Running Condition should be ON_SUCCESS so that the Backup can’t be launch if the
Share is not mounted.
Umount_drive task
Repeat the Mount_drive task but configure the Backup task as predecessor.
The Running condition can be left to ALWAYS as the network share should be disconnected
any way.
The Workflow will looks like the following:
2.3.1.5. Backup Summary

Files
[Backup disk]\*.bck|*.tar|*.bkf X X X
This apply only in case the Backup disk is local to the InfoVista Server.
2.3.2. IP|Reporter LoadBalancer (VF4 mode only)

The server provisioned for VistaMart should have a dedicated filesystem available for
backups. We recommend this filesystem to be secured using RAID 1 (mirroring).
This file system should NOT be used by any other InfoVista component.
Sufficient disk space should be available for Oracle backups, as determined during the
system sizing (Refer to ip|reporter VF4 sizing documentation, available through Ipanema
support).
This size should be at least 1.5 times the database size (Repository Size).
Oracle database backups are stored in the Oracle backup file system, as it has been defined
during VistaMart with embedded Oracle database.
The Oracle IVDB database backup is called the recovery area. It contains all the necessary
information for a full Oracle and VistaMart service.
2.3.2.1. How are backups performed

When you activate the Backups, a full backup of the database datafiles is done.
Then, the next days, incremental backup of all the changes performed on the databases
since last backup are done.
The incremental backups is then, merged to the existing full backup.
The Redolog files are also archived in the recovery area when the gets full.
Beside this, between 2 backups, all the transactions that have been performed since last
backups are saved in the archivelog files.
Once the incremental backups are merged to the full backup, the archivelog files generated
so far are deleted as they are not needed anymore.
2.3.2.2. Content of Recovery Area

When you configure the database in ARCHIVELOG mode, the following files will be backup
in the Flash Recovery Area:
Datafile copies (Up to date copies of the database)
Archived redo logs (transactions changes between 2 daily backups)
Control file copies
Backup pieces (backup)
2.3.2.3. Automatic backup configuration

This step should have been done during the VistaMart installation.
If it is not the case, this should be done through the VistaMart Database Manager Wizard
On a Windows deployment, this can be launched from the Start menu:
Start->All Programs->InfoVista.
On a Linux deployment here are the commands to be run:
root@LB71_srv1 ~]# su oracle

sh-3.2$ export ORACLE_SID=IVDB
sh-3.2$ export ORACLE_HOME=/opt/InfoVista/oracle/product/11.2.0.3
sh-3.2$ export PATH=$PATH:/opt/InfoVista/VistaMart/bin:$ORACLE_HOME/bin
sh-3-2$ cd /opt/InfoVista/VistaMart/bin/
sh-3.2$ ./dbmanager.sh
Launching Database Manager as oracle...
Select the “Configure the Oracle instance” item, and click next the subsequent dialog:
The following information needs to be given for the configuration wizard, to be able to
connect to the database :
Host Name: Database server to connect to (usually the systems primary IP address).
DB Port Number: Unless it has been customized, leave the default value untouched.
SID: The VistaMart database name (IVDB by default).
User Name: Oracle administrator username: sys
Password: Password set during the initial installation for the Oracle administration
account.
The following dialog screen sets up the schedule for the automatic backups. We recommend
using the “Standard” Oracle backup profile for the VistaMart database automated backups.
Backups should be done daily, 7 days a week.
The scheduled time will depend on the time at which external backup program is ran.
Recovery area size should be set to a value equal or higher than the one indicated during the
initial system sizing. It should not exceed the available backup disk space.
Backups should be enabled, and database should be reconfigured.

Please note that this will restart the Oracle database system, and also induce a restart of the
VistaMart Service.
2.3.2.4. Recovery Area Backup

The entire recovery area should be backed up on a regular basis (daily). We recommend
delaying these backups at least two hours after the automatic Oracle backup schedule (4am
if Oracle automated backups are done at 2am for example).
The recovery area is located on the backup filesystem in the following location:
[Backup disk]\InfoVista\oradata\IVDB
VistaMart offers a hook in the Oracle backup procedure for an external script.
This can be used to automatically launch the backup of the files present in the recovery area
right after the Oracle data backup.
This method is preferred, as it will only launch the script execution if the Oracle backup has
been successful (otherwise, corrupted data may be backed up and even overwrite older but
consistent backup data).
To use this hook, create a script in the following directory, in the InfoVista VistaMart
installation directory:
[INSTALL_BASE_DIR]\InfoVista\VistaMart\oracle\user\dbbackup_user.cmd (.sh in a
UNIX environment).
This script should contain the necessary commands to proceed with the file backup. The
output of the script will be written to the following file:
[INSTALL_BASE_DIR]\InfoVista\VistaMart\oracle\user\dbbackup_user.log
Keep in mind that this script will not be executed if a failure occurred during the Oracle
backup.
2.3.2.5. Check Automatic Backup activation

Once the Automatic backups have been configured, you can check if they are running.
To do this, you have to do the following:
Open a dos command then execute (dba_scheduler_jobs.sql)
sqlplus sys/password@localhost/IVDB as sysdba
sql>select job_name, enabled from dba_scheduler_jobs ;
sql>exit
This statement should report the following output :
VM_DFULL_BCK_JOB TRUE
This means the backup job is scheduled and will be executed next time it's scheduled for.
On the other hand if you get the following results:
VM_DFULL_BCK_JOB FALSE
 this means the backup job is scheduled but not active (There are kown issues where the
backup job does not get activated after you have run the procedure).
If this is the case please, contact Ipanema Support or refer to the technical note TN-
0200155-06_Check_automatic_Oracle_DB_backups_in_VF4_mode.pdf ).
2.3.2.6. Changing the Recovery Area location

Some situation may require changing the location of the Oracle backups (recovery area).
Different options are possible:
Change the location in the Oracle configuration.
Use a symbolic link (UNIX) or mount an alternate volume on the current recovery area
path (Windows).
Change the filesystem in the recovery area mountpoint and copy over the data from the
previous filesystem used as the recovery area (UNIX).
Options 2 and 3 are operating system level features. Your system administrator should
manage these changes. Any changes to the recovery area should only be done after
stopping the VistaMart server and Oracle DBMS.
The first option is a bit more complicated. It is described in the following section, we
recommend having it implemented by a system administrator with minimal Oracle
knowledge.
2.3.2.6.1. Reconfiguring the location in Oracle / VistaMart configuration

Following captures bellow are based on a Windows environment. Commands in a UNIX
environment are similar and should need little modification.
Typed in commands are in bold typeface.
Connect to the VistaMart server, using administrator / root account.

Open the windows command line (cmd.exe) or a UNIX terminal.
Set the Oracle SID as an environment variable:
c:\Documents and Settings\Administrator>set ORACLE_SID=IVDB
Start Oracle sqlplus (use the Oracle “sys” password as it has been set during VistaMart
installation):
c:\Documents and Settings\Administrator>sqlplus sys/<password> as sysdba
Check the state of backups:
SQL> archive log list
Verify that automatic archival is Enabled in the results displayed using the above
command.
SQL> select filename, status from v$block_change_tracking;
Verify the backup path in the result of the above command.

SQL> show parameter recovery
Finally check recovery area path and size in this last command:
Disable backups using the VistaMart database manager (cf 2.2.1.3). You must go through all
the configuration screens described earlier, before you can access the screen to disable
backups.
IMPORTANT: We strongly recommend stopping both VistaMart application and
computation services at this point.
Make a backup copy of file

<VistaMart_install_location>\vistamart\config\dbmgr\dbdbmgr.xml
Edit the file using a standard texteditor (Wordpad is recommended on Windows).
Locate the line referring to the current recovery area and change it to the new location.
Do not append the full “InfoVista/oradata/IVDB” path to the Axes value!:
Under UNIX, this might look like (Axe corresponding to the recovery area in italics):
<Axes>
<Axe shared="false" raid="Unknown" mount="/opt/InfoVista" id="1">
<Size value="30.0" unit="GB"/>
</Axe>
<Axe shared="false" raid="Unknown" mount="/opt/recovery2" id="2">
</Axe>
</Axes>
In a Windows environment:
<Axe shared="true" raid="1" mount="F:/backuptest/" id="4">
</Axe>
Save changes and exit.

Create the directory structure in the new recovery area:
mkdir –p /opt/recovery2/InfoVista/oradata/IVDB
mkdir F:\backuptest\InfoVista\oradata\IVDB
We will now change the location for the block tracking file (we will need to stop Oracle at this
point):
SQL> shutdown immediate
Copy the tracking file from the former to the new recovery area:
UNIX:
cp /recovery/InfoVista/oradata/IVDB/db_change_tracking.tr \
/opt/recovery2/InfoVista/oradata/IVDB
Windows (on one line):
copy d:\InfoVista\oradata\IVDB\DB_CHANGE_TRACKING.TR
F:\backuptest\InfoVista\oradata\IVDB
We may now restart and reconfigure the Oracle database tracking:

Connect to SQL plus (database should be idle) and execute the following commands
(Windows example). Note that when typing in multi-lan SQL commands, SQLPlus adds the
line number 2; 3 in front of the line, no need to type it:
SQL> startup mount
ORACLE instance started.
Total System Global Area 968884224 bytes
Fixed Size 1300260 bytes
Variable Size 394266844 bytes
Database Buffers 566231040 bytes
Redo Buffers 7086080 bytes
Database mounted
SQL> alter database

2 rename file 'D:\INFOVISTA\ORADATA\IVDB\DB_CHANGE_TRACKING.TR'
3 to 'f:\backuptest\INFOVISTA\ORADATA\IVDB\DB_CHANGE_TRACKING.TR' ;
Database altered.
SQL> alter database open ;

Database altered
SQL> exit
You can now restart the VistaMart database configuration wizard and re-enable the Oracle
database backups (this will require an Oracle restart). As said earlier, preferably VistaMart
services should be stopped at this point.
Check that changes have been taken into account by typing the three commands in bold
and check that the output reflects the new settings:
C:\Documents and Settings\Administrator>sqlplus sys/ipanema as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Mon Nov 8 17:49:06 2010
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing
Options
SQL> archive log list

Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 1023
Next log sequence to archive 1030
Current log sequence 1030
SQL> select filename, status from v$block_change_tracking;
FILENAME
--------------------------------------------------------------------------
------
STATUS
----------
F:\BACKUPTEST\INFOVISTA\ORADATA\IVDB\DB_CHANGE_TRACKING.TR
ENABLED
SQL> show parameter recovery

NAME TYPE
---------------------------------------------------- -----------------------
VALUE
-------------------------------------------------
db_recovery_file_dest string
F:/backuptest//InfoVista/oradata/IVDB
db_recovery_file_dest_size big integer

100G
recovery_parallelism integer
0
SQL>
We would now recommend launching a manual backup, just as a security measure:

SQL> exec dbms_scheduler.run_job('VM_DFULL_BCK_JOB',TRUE);
PL/SQL procedure successfully completed.
SQL>
This last command should output the last backups recorded on the system. The last one,
should be the manual backup you’ve just made:
SQL> select to_char(start_time,'dd/mm/yyyy hh24:mi:ss'),

2 to_char(end_time, 'dd/mm/yyyy hh24:mi:ss'),
3 status from v$rman_backup_job_details order by start_time asc ;
(…)
TO_CHAR(START_TIME,'DD/MM/YYYY
--------------------------------------------------------------------------
-
TO_CHAR(END_TIME,'DD/MM/YYYYH
--------------------------------------------------------------------------
-
STATUS
-----------------------
08/11/2010 02:00:42
08/11/2010 02:01:06
COMPLETED
08/11/2010 17:53:38
08/11/2010 17:53:55
COMPLETED
The procedure is finished. You have move VistaMart Oracle database location.
2.3.2.7. Backup Summary

Files
[Backup disk]\InfoVista\oradata\IVDB X X
2.4. Backup Summary

Files
~/ipboss/server/domains/uni_boss/config/__active__.ipmuniconf X X
~/ipboss/server/domains/uni_boss/conf/platform/license.ipmsys X
~/ipboss/server/pgbouncer/conf/ X X
~/ipboss/server/postgresql/data.zip X
~/ipboss/server/conf/ipm_domains.conf X
~/ipboss/server/conf/ipboss.conf X
~/ipboss/server/conf/reports_desc.ipmsys X
~/ipboss/server/domains/<domain>/conf/license.ipmsys X
~/ipboss/server/domains/<domain>/config/__active__.ipmconf X
~/ipboss/server/domains/ X X
~/ipboss/server/postgresql/data/ipm_database_users.txt X
~/ipboss/server/postgresql/data/ipm_pg_bouncer.ini X
~/ipboss/server/postgresql/data/postgresql.conf X
~/ipboss/server/postgresql/data/postmaster.opts X
~/uniboss/apacheDS/instances X
~/uniboss/server/conf X
~/uniboss/web_server/webapps X*
~/apache/conf/ X X*
Backupfile.zip X** X**
[Backup disk]\InfoVista\oradata\IVDB X X
[Backup disk]\*.bck|*.tar|*.bkf X X X
X* Backups only needed if specific tuning is made.

X** Salsa V8
3. Restore
3.1. Salsa
3.1.1. Restore procedure can be differentiated in two categories:

Partial restore; restore only one Salsa service configuration files.
Full Restore; restore all the Salsa service configuration files.
3.1.2. Partial Restore

Partial restore may be useful if there is an issue with one of the Salsa service or a
misconfiguration.
3.1.2.1. Salsa V7
3.1.2.1.1. Restore an existing ip|boss domain configuration

If you just want to retrieve a previous configuration file from a specific domain, and you do
not have to restore your whole server, then:
On ip|boss : click on “disable ip|engines” on the target domains and update
On ip|uniboss : Change domain state to “disable” and update
Restore target domain configuration from your backup: copy __active__.ipmconf to its
original directory ~/ipboss/server/domains/<domain>/config
On ip|uniboss : Change domain state to “enable” and update

On ip|boss : click on “enable ip|engines” on the target domain and update
If there is more than one domain to restore repeat those steps for each of the domains.
3.1.2.1.2. Restore a previously removed ip|boss domain configuration

If you just want to retrieve a previous deleted domain you will have to perform the following
steps:
On ip|uniboss: Create a new domain with the exact same name than the one you want to
restore and update.
Once domain is started, edit domain in ip|uniboss and change its state to “disable” and
update.
Once domain is stopped, restore target domain configuration from your backup:
copy __active__.ipmconf to its original directory
~/ipboss/server/domains/<domain>/config
On ip|uniboss : Change domain state to “enable” and update
On ip|boss : click on “enable ip|engines” on the target domain and update

If there is more than one domain to restore repeat those steps for each of the domains.
3.1.2.1.3. Restore Salsa users dictionary

If you just want to restore a previous version of the LDAP dictionary follow the following
steps:
On the ip|uniboss server stop the Salsa Apache Directory Server service.
Once the service is stopped, restore the LDAP dictionary configuration from your backup:
copy the instances directory to its original location ~/apacheDS/instances.
On the ip|uniboss server start the Salsa Apache Directory Server service.
3.1.2.1.4. Salsa V8
From the Zip file generated backup.zip, you can extract the Previous files and restore them
as for v7 version
3.1.3. Full restore
3.1.3.1. Salsa V7
3.1.3.1.1. Restoring the server

As a full restore procedure server’s operating system needs to be reinstalled, the same IP
address MUST be used. The Salsa software needs to be reinstalled, refer to the Salsa
Installation guide for additional help on the installation process.
3.1.3.1.2. Restoring the configuration files

Installation path for this new installation should remain the same than the one you are
attempting to restore. Once Salsa software has been reinstalled stop all Salsa services;
Salsa Apache
Salsa Apache Directory Server
Salsa ipboss Server
Salsa ipuniboss Server
Salsa pgbouncer
Salsa Postgresql
Salsa Web Server
Once the services are stopped restore all backup files to their original path according to the
following table:
Files
~/ipboss/server/pgbouncer/conf/
~/ipboss/server/postgresql/data/
~/ipboss/server/conf/ipm_domains.conf
~/ipboss/server/conf/ipboss.conf
~/ipboss/server/conf/reports_desc.ipmsys
~/ipboss/server/domains/
~/uniboss/apacheDS/instances.
~/uniboss/server/conf
~/uniboss/web_server/webapps.
X* File restore is only needed if one or more web apps have been tuned.
.After restoring all the files Salsa service should be re started.
3.1.3.1.3. Salsa V8
As for Backup, this version provides a restore script that will restore all the Backup files at the
same place.
To restore a backup, the current installation and the installation when the backup has been
done must verify the following criterias:
the product version is the same
the domain location is the same
the list of packages are the same (web server, ip|boss, ip|uniboss)
The restore script must be executed with an administrator account.
The restore script can be executed while services are started or stopped. If they are started,
they will be stopped at the beginning of the script and restarted at the end. You can use the
parameter "-forceStart" to force the the start of salsa services at the end.
For a multi-part installation, the tasks have to be scheduled at the same exact same
time.
This script is located in ~/salsa/tools
The command to launch is:
restore -backupFile <backup.zip file generated with backup script> [ -forceStart]
3.1.4. IP|Reporter Server (VF0 and VF4 mode)

We have 2 kinds of backup files:
.tar.gz files generated by ivbackup tool on Linux/Solaris platform
.bkf files generated by osbackup tool on Linux/Solaris/Windows platform.
3.1.4.1. ivbackup restoration

The backup of the database is a .tar.gz file. So, what you have to do is to extract the files
and set them back where they came from. Once this is done you can start the services.
3.1.4.2. Osbackup restoration

This procedure is valid for backup realized through Cockpit Management Console or directly
through osbackup command.
First, stop all the InfoVista's services:

Infovista Browser
Infovista Collector
Infovista Manager
Browse to ~installed_drive\InfoVista\Essentials\data and rename the collector.db and
manager.db files to save them for future reference.
Restore the database backup file (backup.bkf) with the following commands:
Remember to run the commands from the bin directory of InfoVista, for example:
C:\Program Files\InfoVista\Essentials\bin
osrestore.exe –f C:\Program Files\the_path_to_backup_folder\ipm_backup.bkf  the path of latest backed up

file
<ipreporter server hostname>: C:\Program Files\InfoVista\Essentials\data\manager.db
C:\Program Files\InfoVista\Essentials\data\manager.db  source and destination path to manager DB
<ipreporter server hostname>: C:\Program Files\InfoVista\Essentials\data\collector.db
C:\Program Files\InfoVista\Essentials\data\collector.db  source and destination path to collector DB
The command is split in 3 parts here for the purpose of explanation.(It is just one command)
Note:
The arguments are given with spaces.
The paths to collector and manages databases is specified twice as one indicates source
and the other destination. For an example if you want to extract from the backup to different
location the command would be
osrestore,exe –f C:\Program Files\the_path_to_backup_folder\ipm.backup.bkf C:\Program Files
InfoVista\Essentials\data\manager.db F:\manager.db C:\Program
Files\InfoVista\Essentials\data\collector.db F:\collector.db
When it is finished, restart all the InfoVista's services:

Infovista Browser
Infovista Collector
Infovista Manager
The restore command directive can also be found in the file ipm_backup_readme.txt in the
backup folder.
The server is operational.
3.1.5. IP|Reporter LoadBalancer (VF4 mode only)

Database restoration can be a complex process and differ depending on the type of failure
that has been experienced.
It is strongly recommended to contact Ipanema support before starting the recovery
process.
This section only describes full restoration of the VistaMart environment. Partial restoration
can be used when the system is only suffering a partial failure (accidental file deletion, limited
file system unavailability, corruption). Partial restoration is described in the InfoVista
VistaMart Administration Guide. Depending on the exact failure that has occurred, different
restoration scenarios are possible;
Ipanema Support can assist in helping to determine the exact restoration procedure that
needs to be applied.
Once VistaMart has been reinstalled on the system and the backup restored, you can
perform a Full Restoration of the VistaMart Oracle databases.
Before launching the full restore script, Oracle REDO LOGS have to be removed from
the filesystem in order to be able to import the Oracle backups. This is mandatory if
the backups come from a different Oracle server.
Once REDO LOGS files have been removed you can proceed to the next step.
Note that, you’ll need to change the path of the recovery area, according to your local setup.
On a Windows deployment this can be done using the following command:
Open a Command Line Window
Go to [INSTALL_BASE_DIR]\InfoVista\VistaMart\dbmgr\bin
dbrecoveryfull.bat -Ddatabase.syspw="oracle"
-Ddatabase.recoveryarea.dir="d://InfoVista/oradata/IVDB/restore"
You need to change the path of the recovery area, according to your local setup.
On a Linux deployment this can be done using the following command:
[root@LB71_srv2~]# su oracle
sh-3.2$ export ORACLE_SID=IVDB
sh-3.2$ export ORACLE_HOME=/opt/InfoVista/oracle/product/11.2.0.3
sh-3.2$ export PATH=$PATH:/opt/InfoVista/VistaMart/bin:$ORACLE_HOME/bin
sh-3.2$ cd /opt/InfoVista/VistaMart/dbmgr/bin/
sh-3.2$ ./dbrecoveryfull.sh -Ddatabase.syspw=”oracle"
-Ddatabase.recoveryarea.dir=”/opt/backups/InfoVista/oradata/IVDB/restore"
You need to change the path of the recovery area, according to your local se
Once the script execution is finished you’ll get some warnings messages that may be
ignored. To restart the database you’ll need to stop the database, start the database andalter
the database by resetting the REDO LOGS. This will be done using the following command:
[root@LoadBalancer ~]# sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Mon Mar 24 14:20:14 2014
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning and Real Application Testing options
SQL> shutdown immediate

Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;

ORACLE instance started.
Total System Global Area 868511744 bytes

Fixed Size 2233280 bytes
Variable Size 562039872 bytes
Database Buffers 297795584 bytes
Redo Buffers 6443008 bytes
Database mounted.
SQL>ALTER DATABASE OPEN RESETLOGS;
Database altered.
SQL>exit
www.ipanematech.com | Beyond the Network…
ABOUT IPANEMA TECHNOLOGIES
Ipanema provides enterprises with a direct connection between application performance and their
business requirements. With Ipanema Technologies, enterprises automatically understand which
applications use the network and deliver guaranteed performance to each user. Enterprises can
support their strategic IT transformations (like cloud computing and Unified Communications) and
control Internet growth while reducing their IT expenses. Ipanema’s customers range from mid-
sized companies to enterprises with 1,000s of sites. For Enterprises, Ipanema is available as a
Product through an international network of Certified Channel Partners, and as a Service through
Managed Service Providers and Telecom Operators' Managed Services. For SMBs, Ipanema is
available as a Service through Ipanema's AppsWork™ Authorized Partners network.
For more information, visit www.ipanematech.com
Copyright © 2012, Ipanema Technologies - All rights reserved. Ipanema and the Ipanema logo
are registered trademarks of Ipanema Technologies. The other registered trademarks and product
names mentioned in this document are the property of their respective owners.

Salsa 8 Backup And-Restore

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

Salsa 8 Backup And-Restore

Uploaded by

Copyright:

Available Formats

How to Backup and Restore Overall

www.ipanematech.com | Beyond the Network…

Revision All all all - - -

2.1.1. License file

2.1.2.1. Installation path

2.1.2.2. Initial backup

Following files needs to be saved:

Additionally, these files also need to be backed up on a regular basis:

2.1.2.3. Maintenance and exploitation backup

On a daily basis, you need only to save the following files:

Uniboss domains configuration files

In addition following files needs to be saved from the

There is no need for additional file backup.

2.1.2.4. DRP backup

Following files needs to be saved from the ~/ipboss/server/domains/uni_boss

2.1.3.1. Installation path

2.1.3.2. Initial backup

No files to back up here.

There is no file to backup up upon first installation.

2.1.3.3. Maintenance and exploitation backup

There is no file to backup at this stage.

2.1.3.4. DRP backup

2.1.4.1. Installation path

2.1.4.2. Initial backup

2.1.4.3. Maintenance and exploitation backup

2.1.4.4. DRP backup

2.1.5. Salsa Weberver

2.1.5.1. Installation path

2.1.5.2. Initial backup

There is no file to backup up upon first installation.

2.1.5.3. Maintenance and exploitation backup

There is no file to backup at this stage.

2.1.5.4. DRP backup

~/salsa/tools/backup –backupFile <Path to backup result zip file>

2.2.1. Backup summary

Initial Operation DRP

X* Backups only needed if specific tuning is made.

The reporting part backups consist in the 2 Databases:

2.3.1. IP|Reporter Server (VF0 and VF4 mode)

2.3.1.1. General Recommendations

Linux/Solaris (8 instances) Windows (4 instances)

2.3.1.2. OSBackup tool (InfoVista 4.2, InfoVista 4.3)

Modify the path of manager.db and collector.db according to your installation.

2.3.1.3. Point-in-time copy technology (snapshots)

Release IVServer instance checkpointed

InfoVista login (with administration privileges) to perform database checkpoint

Password of the user given above

-gzip: gzip backup file (requires gzip)

To obtain the best possible performances, it is recommended to separate the databases

2.3.1.4. VistaCockpit Backup Configuration (Windows, Linux, Solaris)

Create the Backup task

Choose the schedule options

2.3.1.4.2. Configure task flow to Backup on an external Network Drive

Select the Target (IP|reporter server)

The Workflow will looks like the following:

2.3.1.5. Backup Summary

Initial Operation DRP

2.3.2. IP|Reporter LoadBalancer (VF4 mode only)

2.3.2.1. How are backups performed

2.3.2.2. Content of Recovery Area

2.3.2.3. Automatic backup configuration

On a Linux deployment here are the commands to be run:

root@LB71_srv1 ~]# su oracle