JOURNAL BASED BACKUP

INTRODUCTION:

Journal Backup is appropriate for backing up files systems with small or moderate
amounts of change activity between backup cycles. Very large amounts file changes
between backup cycles will result in very large change journals, and very large
change journals pose memory and performance problems which may negate the benefits
of journal backup. For example, creating, deleting, or renaming/moving very large
directory trees may also negate the benefit of using journal backup instead of
normal incremental backup.

Journal backup is not intended to be a complete replacement for traditional

incremental backup. The goal of journal backup is to track all file system changes
in the change journal and to make every attempt to keep the journal synchronized
with what has been backed up.

JOURNAL BASED BACKUP ON OPERATING SYSTEMS:

AIX operating systems on AIX, journal-based backup is supported on JFS and JFS2
file systems.

Linux operating systems on Linux, journal-based backup is supported on Ext2, Ext3,

Ext4; XFS, ReiserFS, JFS, VxFS, and NSS, and for a local file system shared through
NFS. GPFS is not supported for journal-based backups

INSTALLATION AND ENABLING JOURNAL BASED BACKUP:

On AIX, the Tivoli Storage Manager journal daemon can be configured by editing the
journal daemon configuration sample file, tsmjbbd.ini.smp, and saving it as
tsmjbbd.ini. Both the configuration sample file and the saved file should be in the
default install directory. The journal configuration file, (tsmjbbd.ini), needs as
a minimum a list of the file systems to monitor. These two lines are sufficient:
[JournaledFilesystemSettings]
JournaledFileSystems=/home

After the configuration file is created, start the journal daemon using the script
file:/usr/tivoli/tsm/client/ba/bin/rc.tsmjbb. The journal will write initialization
information to the errorlog. When you are satisfied that the journal is working
correctly, you should run the script file,
/usr/tivoli/tsm/client/ba/bin/jbbinittab. Running the script file will make entries
in /etc/inittab, so that the journal will begin running when you restart your
system.

tsmjbbd.ini file entires as follows

[JournaledFileSystemSettings./SAN]
Errorlog=jbberror.log
JournalDir=/SAN/TSM
JournaledFileSystems=/SAN
JournalDBSize=0x10000000
NotifyBufferSize=0x00200000

Create new stanza for /SAN FS

servername SAN
Nodename WWPPVLMQMA4_SAN
TCPSERVERADDRESS 10.172.200.119
TCPClientaddress 10.172.208.18
COMMmethod TCPip
TCPPort 1500
Passwordaccess generate
SCHEDMODE PROMPTED
schedlogr 7 D
errorlogr 7 D
LARGECOMMBUFFERS yes
TCPBuffsize 31
TCPNodelay Yesnew file (copy)
TCPWindowsize 63
TXNBytelimit 25600
schedlogname /opt/tivoli/tsm/client/ba/bin/sansched.log
errorlogname /opt/tivoli/tsm/client/ba/bin/sanerror.log
DOMAIN /SAN

Create new opt file for SAN

dsmsan.opt
add the below entry on dsmsan.opt
servername SAN

Server Side:

Register new node on TSM server with Nodename=WWPPVLMQMA4_SAN

JOURNAL BASED BACKUP SERVICES:

Journal based backup service (tsmjbbd) is entered in /etc/init/d

Running services can be monitored in the client system using ps -ef | grep command.

Starting journal based backup Services :

service tsmjbbd start

Stopping journal based backup Services:

service tsmjbbd stop

PERFORMING JOURNAL BASED BACKUP:

Full and partial incremental backup

An incremental backup backs up only new and changed files. The type of incremental
backup depends on what object is selected to be backed up.

If you select entire file systems, the backup is a full incremental backup. If you
select a directory tree or individual files, the backup is a partial incremental
backup.

The first time that you run a full incremental backup, Tivoli® Storage Manager
backs up all the files and directories that you specify. The backup operation can
take a long time if the number of files is large, or if one or more large files
must be backed up. Subsequent full incremental backups only back up new and changed
files. The backup server maintains current versions of your files without having to
waste time or space by backing up files that exist in Tivoli Storage Manager server
storage.

Depending on your storage management policies, the Tivoli Storage Manager server
might keep more than one version of your files in storage. The most recently backed
up files are active backup versions. Older copies of your backed up files are
inactive versions. However, if you delete a file from your workstation, the next
full incremental backup causes the active backup version of the file to become
inactive. You can restore an inactive version of a file. The number of inactive
versions that are maintained by the server and how long they are retained is
governed by the management policies that are defined by your Tivoli Storage Manager
server administrator. The active versions represent the files that existed on your
file system at the time of the last backup.

To start a full or partial incremental backup through command line use the
incremental command and specify file systems, directory trees, or individual files
to include in the backup.

During an incremental backup, the client queries the server or the journal database
to determine the exact state of your files since the last incremental backup. The
client uses this information for the following tasks:

Back up new files.

Back up files whose contents changed since the last backup.

A directory is backed up in any of the following circumstances:

The directory was not previously backed up
The directory permissions changed since the last backup
The directory Access Control List changed since the last backup
The directory Extended Attributes changed since the last backup
The directory modification time stamp changed since the last backup

Directories are counted in the number of objects that are backed up. To exclude
directories and their contents from backup, use the exclude.dir option.
Expire backup versions of files on the server that do not have corresponding
files on the workstation. The result is that files that no longer exist on your
workstation do not have active backup versions on the server. However, inactive
versions are retained according to rules defined by the Tivoli Storage Manager
administrator.
Rebind backup versions if management class assignments change. Only objects
that have active backup versions are bound again. Objects for which only inactive
backup versions exist are not bound again.

PERFORMING JOURNAL BASED RESTORE:

Restore processing with journal-based backups (AIX and Linux)

The journal service attempts to identify changes that are made to a file as the
result of a restore operation. If a file is unchanged since it was restored, it is
not backed up again during the next journaled backup.The presumption is that you
are restoring a file because it contains the data you need, so there is no point to
backing up the file again when the next journal backup occurs. Changes to restored
files that occur after the files are restored must be recognized as new changes and
the file is processed in the next journal backup.

When an active journal exists for a particular file system, the backup-archive
client notifies the journal daemon when a file is about to be restored. Any changes
to the file that occur within a short window in time after the journal daemon is
notified are assumed to be a result of the file being restored. These changes are
not recorded and the file is not included in the next journal backup.

In most cases, journal processing correctly identifies file changes that are
generated as the result of the file being restored and prevents the file from being
backed up by the next journal backup.

Systemic system delays, whether caused by intensive I/O or file system latency,
might prevent a restore operation from starting in the time frame allotted by the
journal daemon once it is notified that a restore is about to take place. If such a
delay occurs, changes made to the file are assumed to be new changes that occurred
after the file was restored. These changes are recorded, and the file is included
in the next journal backup. Things like systemic processing delays and file system
latency are beyond the control of Tivoli® Storage Manager and are simply recognized
limitations of journal-based backups.

restore /vol1/BAM3/var/data/titanium-temporal/partition-0/sstable/hv/03-
0001/data.bin /tmp/ -ina
restore /vol1/BAM3/var/data/titanium-temporal/partition-0/sstable/hv/03-0001/key-
index.bin /tmp/ -ina
restore /vol1/BAM3/var/data/titanium-temporal/partition-0/sstable/hv/03-
0003/data.bin /tmp/ -ina
restore /vol1/BAM3/var/data/titanium-temporal/partition-0/sstable/hv/03-0003/key-
index.bin /tmp/ -ina