You are on page 1of 3

10/2/2017 BackupandrestoreinLTEOMS

LTERadioAccess,Rel.RL50,OperatingDocumentation,Issue03>Administer>AdministeringandSecurityinLTEiOMS>
Backupandrestore

Backup and restore in LTE OMS


Making regular backup copies of the software and databases of the LTE OMS ensures that a user has a functional copy of the software which can be used if
there are problems with the software or hardware, for example, a logical disk crash or a configuration error.
Backup and restore operation can be performed in two different ways:
remote backup and restore
The remote backup functionality enables the NetAct operator a remotely triggered backup of LTE OMS system data. Remote operation can be
scheduled from NetAct backup scheduler (regular or periodical backup) or can be initiated from NetAct using NWI3 interface request. All
operation is planned and executed remotely using NetAct.
The remote restore functionality enables downloading of LTE OMS backup file (result file from partial or custom backup operation) remotely from
NetAct. The downloaded backup file can be activated immediately in the LTE OMS or activation can be triggered later on (except in cases of full
backup). The full restore is not available remotely because the system must be booted using an external USB boot device.

Remotebackupandrestoreisthepreferredwayofexecutingbackupandrestoreoperations.FormoreinformationseeManagingOMSSoftwareUsingNetAct.

local LTE OMS backup and restore command line interface


The LTE OMS provides CLI based tools in order to perform local backup and restore operation of LTE OMS data. This functionality requires
manual commands to create the backup file as to upload it from LTE OMS to an external storage. A user may also create the backup directory
manually if it is not yet created. The backup directory is located in /var/mnt/local/backup/SS_Backup.
It is recommended that person who deals with backup, restore actions as well with scripts, has basic knowledge of Linux and a good understanding of RPM
(see the RPM man pages for detailed information).

NOTICE:Beforeexecutinganylocalbackupandrestorerelatedcommandorscriptmakesurethatthereisnoremoteoperationongoing.

Users can make a full, a partial, or a custom backup of the software. All types of backups are made using the omsbr_backup CLI command.
Users can restore the whole system or a part of the system with the omsbr_restore CLI command.
When running the backup and restore commands, users must be logged into the LTE OMS as root.

Ifthebackuporrestoreisexecutedremotely,considerusingscreentool.SeesectionEmulatingterminalwiththescreencommandinthisdocument.

Backup types
A backup can be a full, partial, or custom backup. A backup is modular, meaning that the backup procedure consists of executing backup modules. Each
module can create the backup archive of a backup item, for example the database backup module creates a backup of the databases. Note that all items are
not necessarily used in all deployments. The approximated backup sizes are:
Full backup takes around 3.5-9 GB.
Partial backup takes about <100 MB.
Custom backup takes about <50 MB.
Note that the backup should be taken when there are no major on-going activities in the network element. For example, the backup may occasionally fail if the
LDAP directory is manipulated at the time when the backup is taken.
A full backup includes the following items:
system image, including variable data and configuration files
databases
LDAP directory
system restoration tools
A partial backup is similar to full backup, except what comes to first item regards system image, not included it here; only variable data and
configuration files are included on partial backup.
A custom backup allows users to choose the backup items to include in the backup.
During the backup procedure, the local image is not backed up, but regenerated from the system image when it is restored. A backup module synchronizes
the local variable data and configuration files from the local image to the system image before a backup is made.
The backup modules first create individual backup files of the application file systems, databases, LDAP directory, and system restoration tools. The individual
backup files are stored in temporary subdirectories in the directory
/var/mnt/local/backup/SS_Backup/tar
Finally, the system image module makes the system image backup and combines it with the individual backup files into a single compressed tar file that is
located in
/var/mnt/local/backup/SS_Backup
The backup scripts and the configuration files are located in the directory
/etc/opt/Nokia_BP/fsbackup

LTE OMS backup file content and file naming


Since LTE OMS backup operations are performed using FlexiPlatform tools, the content of LTE OMS data set that is preserved in full and partial backup
operations is explicitly defined at FlexiPlatform level. In this regard, to control the amount of data to be preserved, LTE OMS manages configuration files that
specify which part of the directory content is included and excluded during backup operations. These configuration files are available in
/etc/opt/Nokia_BP/fsbackup/backup.c directory.

LTE OMS generates backup filename when the archive filename was not specified by the operator during execution of backup script using CLI. LTE OMS
http://localhost:9090/informationbrowser/index.jsp 1/3
10/2/2017 BackupandrestoreinLTEOMS
LTE OMS generates backup filename when the archive filename was not specified by the operator during execution of backup script using CLI. LTE OMS
generates backup filename when no filename is explicitly specified during execution of backup script locally.
The LTE OMS backup filename structure is as follows:
<OMS_Id>_<OMSProduct>_<backupType_[backupPart]>_<SWRelease>_<date&time>.<filecompressionextension>
where:
OMS_Id is a unique LTE OMS identifier of the network,
OMSProduct is a product type (lte),
backupType is a type of backup (full, partial, custom),
backupPart is a parameter that refers to the specific backup content (which is used in case of the custom type of backup only); the possible values
of the backupPart parameter are as follows:
DB_[databasename] is the name of included database (for example: DB_DB_Topology),
LD if LDAP directory is included,
SI if entire system image is included,
VI if configuration files and variable data on the system image are included,
RT if system restoration tools are included,
HD if home directory is included,
SWRelease is the active software set name,
date&time is the backup's creation date and time in a yyyymmdd_hhmmss format,
filecompressionextension - tar.gz.
Examples:
OMS1_lte_full_R_GOMS<oms_build>.release_oms_20130517_092430.tar.gz
OMS23_lte_partial_R_GOMS<oms_build>.release_oms.corr10_20130516_152805.tar.gz
OMS4_lte_custom_DB_DB_Alarm_DB_DB_Topology_LD_VI_R_GOMS<oms_build>.release_oms.corr44_20130520_094500.tar.gz

Backup logs
A backup operation creates entries into the system log, a cumulative backup log, and a backup-specific log.
The system log (syslog) contains entries of when the backup started and by whom, if it was interrupted and the status of the backup (succeeded or failed.) It
is located in the directory /var/log.
The following are examples of syslog entries.
Example:
The backup process started:

Mar113:40:06infoCLA0logger:SYSLOG(fsbackup)
Startingbackupprocedure

Example:
The user interrupted the backup process:

Mar113:50:39infoCLA0logger:SIGINT(fsbackup:_trapSigInt)
UserinterruptEXITCODE2

Example:
The backup process failed:

Mar113:50:39infoCLA0logger:SYSLOG(fsbackup:_trapSigExit)
BackupfailedwithERRORS(OMS<OMS_ID>_<OMS_product>_<backup_type>_R_GOMS<OMS_build>.release_oms.corr<corr_number>_<time_stamp>.log)

Example:
The backup process succeeded:

Mar113:50:39infoCLA0logger:SYSLOG(fsbackup:_trapSigExit)
finishedOK!(OMS<OMS_ID>_<OMS_product>_<backup_type>_R_GOMS<OMS_build>.release_oms.corr<corr_number>_<time_stamp>.log)

The cumulative backup log, backup.log, contains log entries for all backups and restore operations. It is located in the directory
/var/mnt/local/backup/SS_Backup/log
In the cumulative backup log, a log entry for a backup consists of several rows. The rows are numbered, and for each backup the numbering starts from 1.
The cumulative backup log entries contain the following information:
the name of the backup log, including the start time of the backup
the end time of the backup
the status of the backup (succeeded or failed)
the command used to start the backup including the options
the name of the user who started the backup
the size of the backup archive file
the name of md5 checksum of the backup archive file.
Each backup also has a backup-specific log. It contains information on everything that occurred during the backup. If the backup failed, user can look for
errors in the backup-specific log.

The name of the backup-specific log file includes the type of the backup (full, partial, or custom), the name of the delivery, and the backup execution date and
http://localhost:9090/informationbrowser/index.jsp 2/3
10/2/2017 BackupandrestoreinLTEOMS
The name of the backup-specific log file includes the type of the backup (full, partial, or custom), the name of the delivery, and the backup execution date and
time.
The backup-specific log file is stored in the backup directory /var/mnt/local/backup/SS_Backup/log

Restore operation types


A partial restore may be necessary, for example, if the database(s) or LDAP directory is faulty. To enable the partial restoring, the system must be running.
The omsbr_restore command is used for restore operations:
restoring all database backups
restoring one specified database backup
restoring LDAP directory backup
restoring a single file or a subdirectory

Notethatallitemsarenotnecessarilyusedinalldeployments.

A full restore is required when the system cannot be repaired using a partial backup and a user needs to restore the whole system from the backup archive.
During a full restore, the user restores all backup items: application file systems, databases, LDAP directory, and the system image.
A broken system image usually causes a boot loop. Reasons for that include a logical disk crash, a corrupted file system or an accidental deletion of files or
directories on the system image. The system must be booted using an external USB boot device, for example a USB flash memory drive.

Backup scheduling and storing


It is recommended to always create a full backup before and after a software upgrade. It is recommended to make a partial backup every night. Backups can
be scheduled using a cron (a daemon used for executing scheduled commands). For instructions, see Scheduling backups in OMS.
Note that the backup archive, in both full and partial backup, takes up a large amount of disk space.
Full backup takes around 3.5-9 GB.
Partial backup takes about <100 MB.
Custom backup takes about <50 MB.
If a user creates the backup frequently, the disk soon becomes full. To avoid this, the user needs to delete old backup files to release disk space for the new
ones.
It is also recommended that user keeps a backup history for a certain period of time by moving the existing backup file to an external server before executing
a new backup. It is recommended to keep at least the full backup and the latest partial backup, but it is also recommended to keep a longer history of partial
backups. For example, if a database becomes corrupted and this is not noticed immediately, the latest partial backup may also contain the corrupted data. In
such a case, it is necessary to search through older partial (or full) backups to find the latest database backup that is not corrupted.

Id:DN0962925 2014NokiaSolutionsandNetworks

http://localhost:9090/informationbrowser/index.jsp 3/3