Novell SENTINEL LOG MANAGER 1.0.0.5 - 03-31-2010, Руководство администратора

Страница: 45 / 168

Configuring Data Storage 45
no
vd
ocx
(e
n)
19
Fe
bru
a
ry
20
10
Š
For Event Data: Once a day, at midnight UTC (GMT)
Š
“Restoring Raw Data from Tape” on page 45
Š
“Restoring Event Data from Tape” on page 45
Restoring Raw Data from Tape
To restore raw data, copy the data from tape back into its original location (maintaining the original
directory hierarchy). The Sentinel Log Manager database keeps track of what files were deleted, so
you will need to update the entry in the database to inform it that this raw data file is no longer
deleted. To do so, execute an
UPDATE SQL
command similar to the following for each raw data file
you have restored:
UPDATE raw_data_files SET state = 'ARCHIVED' WHERE file_name = '/6D029DD0-
7F53-102C-B23E-000C294414C6/2009-01/10-0100.zip'
Updating the database will allow you to view the raw data file in the list of raw data files under the
Storage > Raw Data tab of the Sentinel Log Manager user interface.
Alternatively, as the raw data is a text file, you can extract and then read the extracted raw data by
using a text file reader.
Restoring Event Data from Tape
To restore event data, copy the data from tape back into its original location (maintaining the
original directory hierarchy). The Sentinel Log Manager database keeps track of what event
partitions were deleted, so you will need to update the entry in the database to inform it that this
partition is no longer deleted. To do so, execute an
UPDATE SQL
command similar to the following
for each event partition you've restored:
UPDATE ixlog_part SET state = 60 WHERE name = '20090811_408E7E50-C02E-4325-
B7C5-2B9FE4853476'
Where, the value for
name
is the directory name for the partition.
NOTE: Updating the database will allow you to perform searches and run reports on the data in this
event partition by using the Sentinel Log Manager user interface.
As stated earlier in the NOTE above, Sentinel Log Manager will again begin to manage the life
cycle of that partition and will eventually delete it again based on the same criteria that it deleted it
in the first place. You can get around this by creating an additional retention policy with a very long
minimum retention period and then reassigning the partition to use the new retention policy, as
follows:
UPDATE ixlog_part SET ret_pol_id = '6faa7ec0-7f73-102c-bd20-001676e4a757'
WHERE name = '20090811_408E7E50-C02E-4325-B7C5-2B9FE4853476'
Where, the value for
name
is the directory name for the partition and the value for
ret_pol_id
is
the id of the retention policy as listed in the md_config table.