StorageTek Storage Archive Manager and StorageTek QFS Software File System Recovery Guide Release 5.4 E42065-02 |
|
Previous |
Next |
This section outlines the recovery processes that you use when an entire SAM-QFS file system is corrupted or lost. The procedures vary, depending on the type of file system involved and the type of backup and recovery preparations that you have made. But there are two basic tasks that you have to perform:
Before you begin, please note: if you are recovering from the loss of a SAM-QFS metadata server, make sure that you have finished Restoring the SAM-QFS Configuration, as described in Chapter 3, before proceeding further. The procedures in this chapter assume that the SAM-QFS software is installed and configured as it was prior to the loss of the file system.
Before you can recover files and directories, you must have somewhere to put them. So the first step in the recovery process is to create an empty, replacement file system. Proceed as follows:
sammkfs
CommandLog in to the file-system metadata server as root
.
root@solaris:~#
Unmount the file system, if it is currently mounted. Use the command umount
mount-point
, where mount-point
is the directory on which the file system is mounted.
Open the /etc/opt/SUNWsamfs/mcf
file in a text editor, and check the hardware configuration. If you have had to change hardware, edit the file and save the changes.
In the example, we replace the equipment identifiers for two failed disk devices with those of their replacements. Note that the equipment ordinals remain unchanged:
root@solaris:~#vi
/etc/opt/SUNWsamfs/mcf
# Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #----------------------- --------- --------- --------- ------ ------------- samqfs1 100 ms samqfs1 on/dev/dsk/c1t3d0s3
101 md samqfs1 on/dev/dsk/c1t4d0s5
102 md samqfs1 on # Tape library /dev/scsi/changer/c1t2d0 800 rb lib800 on .../lib800_cat /dev/rmt/0cbn 801 li lib800 on /dev/rmt/1cbn 802 li lib800 on:wq
root@solaris:~#
Check the mcf
file for errors. Use the command sam-fsd
.
The sam-fsd
command is reads SAM-QFS configuration files and initializes the software. It will stop if it encounters an error:
root@solaris:~# sam-fsd
If the sam-fsd
command finds an error in the mcf
file, edit the file to correct the error and recheck as described in the preceding step.
In the example below, sam-fsd
reports an unspecified problem with a device. This is probably a typo in an equipment identifier field:
root@solaris:~# sam-fsd
Problem in mcf file /etc/opt/SUNWsamfs/mcf for filesystem samqfs1
sam-fsd: Problem with file system devices.
root@solaris:~#
When the sam-fsd
command runs without error, the mcf
file is correct. Proceed to the next step.
The example is a partial listing of error-free output:
root@solaris:~# sam-fsd Trace file controls: sam-amld /var/opt/SUNWsamfs/trace/sam-amld cust err fatal ipc misc proc date size 10M age 0 ... Would start sam-archiverd() Would start sam-stagealld() Would start sam-stagerd() Would start sam-amld() root@solaris:~#
Tell the SAM-QFS software to read the mcf
file and reconfigure itself accordingly:
root@solaris:~#samd
config
Create the replacement file system. Use the command sammkfs
family-set-name
, where family-set-name
is the name of the file system.
In the example, we recreate file system samqfs1
:
root@solaris:~#sammkfs
samqfs1
Recreate the mount point directory for the file system, if necessary.
In the example, we recreate the directory /samqfs1
:
root@solaris:~#mkdir
/samqfs1
Back up the operating system's /etc/vfstab
file.
root@solaris:~#cp
/etc/vfstab /etc/vfstab.backup
Open the /etc/vfstab
file in a text editor. If the /etc/vfstab
file does not contain mount parameters for the file system that you are restoring, you will have to restore the mount parameters.
In the example, the SAM-QFS server is installed on a replacement host. So the file contains no mount parameters for the file system that we are restoring, samqfs1
:
root@solaris:~#vi
/etc/vfstab
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------- ------ ---- ------- ------------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ...
If possible, when you must restore mount parameters, open a backup copy of the original /etc/vfstab
file and copy the required line into the current /etc/vfstab
file. When the changes are complete, save the file and close the editor.
In the example, we have a backup copy, /zfs1/sam_config
/20140127
/etc/
vfstab
. So we copy the line for the samqfs1
file system from the backup copy and paste it into the current /etc/vfstab
file:
root@solaris:~#vi
/zfs1/sam_config
/20140127
/etc/
vfstab.20140127
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------- ------ ---- ------- ------------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ...samqfs1 - /samqfs1 samfs - yes stripe=1,bg
:q
root@solaris:~#vi
/etc/vfstab
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------- ------ ---- ------- ------------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ...samqfs1 - /samqfs1 samfs - yes stripe=1,bg
:wq root@solaris:~#
Mount the file system.
In the example, we mount the file system samqfs1
:
root@solaris:~#mount
/samqfs1
Now, start Restoring Directories and Files.
Once you have recreated the base file system, you can start to restore directories and files. There are two possible approaches:
Restoring Files and Directories from a samfsdump
(qfsdump
) Recovery Point File is by far the best option, if you have created and safely stored recovery points on a regular basis.
This approach returns the file system to full functionality immediately, because it restores the file-system metadata. An archiving file system can immediately access data on archival media and stage files back to the disk cache, either immediately or as-needed, when users access files. Files are restored with their original attributes.
If the recovery point contains data as well as metadata, this approach is also the only way to restore stand-alone (non-archiving) file systems that are not backed up by third-party applications.
Restoring Files and Directories from Archival Media without a Recovery Point File using a recovery script and the SAM-QFS star
utility.
samfsdump
(qfsdump
) Recovery Point FileWhenever possible, you should base file-system recovery efforts on the most recent available recovery point file. This approach is by far the fastest, most reliable, most thorough, and least labor-intensive way of recovering from the failure of a SAM-QFS file system. So, if a recovery point file exists, proceed as follows:
Log in to the file-system metadata server as root
.
root@solaris:~#
If you have not already done so, stop archiving and recycling using the procedures in "Stopping Archiving and Recycling Processes".
Identify the most recent available recovery point file.
In the example, we have been creating dated recovery point files for the file system samqfs1
in a well-known location, the subdirectory samqfs1_recovery
on the independent file system /zfs1
. So the latest file is easy to find:
root@solaris:~#mkdir
/zfs1/samqfs1_recovery/
20140321 20140322 2014032320140324
root@solaris:~#
Change to the mount-point directory for the recreated file system.
root@solaris:~#cd
/samqfs1
root@solaris:~#
Restore the entire file system relative to the current directory. Use the command samfsrestore
-T
-f
recovery-point-file
-g
logfile
or the QFS-only command qfsrestore
-T
-f
recovery-point-file
-g
logfile
, where:
-T
displays recovery statistics when the command terminates, including the number of files and directories processed and the number of errors and warnings.
-f
recovery-point-file
specifies the path and file name of the selected recovery point file.
-g
logfile
creates a list of the directories and files that were online when the recovery point was created and saves the list to the file specified by logfile
. If you are restoring an archiving file system, this file can be used to automatically stage files from archival media, so that the disk cache is in the same state as it was at the time that the recovery point was created.
In the example, we restore the file system samqfs1
from the recovery point file /zfs1/samqfs1_recovery/20140324
and log the online files in the file /root/20140324.log
:
root@solaris:~#samfsrestore
-T
-f
/zfs1/samqfs1_recovery/
20140324
\-g
/root/20140324.log
samfsdump statistics: Files: 52020 Directories: 36031 Symbolic links: 0 Resource files: 8 File segments: 0 File archives: 0 Damaged files: 0 Files with data: 24102 File warnings: 0 Errors: 0 Unprocessed dirs: 0 File data bytes: 0 root@solaris:~#
If you have restored a standalone (non-archiving) file system, the file-system metadata and file data that were saved in the recovery-point file have been restored. Stop here.
In most cases, do not restage files from archival media to disk following a file system recovery. Let users stage files as needed, by accessing them.
This approach automatically prioritizes staging according to user needs and maximizes the availability of the file system at a time when it may have been offline for some time. Only required files are staged, and the total staging effort is usually spread over a period of time. This helps to insure that file system resources, such as drives, are always available for high priority tasks, such as archiving new files and staging urgently required user data. This approach also reduces the administrative effort associated with recovery.
If you must restage the files that were resident in the disk cache prior to a failure, use the command /opt/SUNWsamfs/examples/
restore.sh
logfile
, where logfile
is the path and file name of the log file that you created with the -g
option of the samfsrestore
(qfsrestore
) command.
The restore.sh
script stages the files listed in the log file. These are the files that were online when the samfsrestore
(qfsrestore
) recovery point file was created.
If thousands of files need to be staged, consider splitting the log file into smaller files and running the restore.sh
script with each in turn. This spreads the staging effort over a period of time and reduces interference with archiving and user-initiated staging.
If you have to restore an archiving file system from a recovery point file that is not completely current, the resulting file system may contain damaged files. In a damaged file, the metadata does not point to locations in the archive that hold copies of valid file data. The restored metadata may point to media that have been recycled, damaged, lost, or replaced since the recovery point was created.
Damaged files are irretrievably lost if there are indeed no archived copies of the data. But, if files were archived after a given recovery point was created, the archive may contain copies that the recovery point metadata does not record. So you may be able to undamage and recover at least some of your damaged files. Proceed as follows:
If you have not already done so, log in to the file-system metadata server as root
.
root@solaris:~#
Identify the most recent available archiver log file.
If the archiver log on the server is still available, it is likely to contain the most recent information. Otherwise, you will need to use a backup copy.
In the example, we have the archive log for the file system, samqfs1.archiver.log
, on the server in /var/adm/
and we have been maintaining dated archiver log file copies in a well-known location, the subdirectory samqfs1_recovery/archlogs
on the independent file system /zfs1
. So the we have both the latest file, samqfs1.archiver.log
, and a recent backup, 20140324
:
root@solaris:~#dir
/zfs1/samqfs1_recovery/archivelogs
20140322 20140323 20140324 root@solaris:~#
In the newly restored file system, identify any damaged files. Use the command sfind
mountpoint
-damaged
, where mountpoint
is the directory where the recovered file system is mounted.
In the example, we start the search in the directory /samqfs1
and find six damaged files:
root@solaris:~#sfind
/samqfs1
-damaged
./genfiles/ay0 ./genfiles/ay1 ./genfiles/ay2 ./genfiles/ay5 ./genfiles/ay6 ./genfiles/ay9 root@solaris:~#
Search the most recent copy of the archiver log for entries relating to each of the damaged files. Use the command grep
"
file-name-expression
"
archiver-log
, where file-name-expression
is a regular expression that matches the damaged file and archiver-log
is the path and name of the archiver log copy that you are examining.
In the example, we search the file genfiles/ay0
:
root@solaris:~#grep
"
genfiles\/ay0
"
/var/adm/samqfs1.archiver.log
When you find an entry for a file, note the media type, volume serial number, and position of the archive (tar
) file where the data file is archived. Also note the file type, since this will affect how you restore the file.
In the example, we locate the file genfiles/ay0
. The log entry shows that it was archived (A
) on March 4, 2014 at 9:49 PM using LTO (li
) volume VOL012
. The file is stored in the archive file located at position 78
(0x78
). It is a regular file, type f
:
root@solaris:~#grep
"genfiles\/ay0 "
/var/adm/samqfs1.archiver.log
A
2014/03/04
21:49
:15li
VOL012
SLOT12 allsets.178
.1 samqfs1 7131.14 8087 genfiles/ay0f
0 51 root@solaris:~#
For a full explanation of the fields in archiver log entries, see Appendix A, "Understanding the Archiver Log".
If you do not find an entry for a damaged file in the current archiver log copy, repeat the search using any backup archive logs that were created after the recovery point file was created.
Archiver logs are rolled over frequently. So, if you retain multiple archiver log copies, you may be able to recover damaged files using archive copies that were made before the period covered by the current archiver log.
Next, Identify Files that Were Archived After the Recovery Point Was Created.
Typically, some files are archived after the last recovery point was created and prior to the loss of a file system. Since the metadata for these files are not in the recovery point file, the files are not recovered when you run samfsrestore
. But the files do reside on archival media, so you can recover them to their proper place in the file system using the archive logs.
If you have not already done so, log in to the file-system metadata server as root
.
root@solaris:~#
Identify the most recent available archiver log file.
If the archiver log on the server is still available, it is likely to contain the most recent information. Otherwise, you will need to use a backup copy.
In the example, we have the archive log for the file system, samqfs1.archiver.log
, on the server in /var/adm/
and we have been maintaining dated archiver log file copies in a well-known location, the subdirectory samqfs1_recovery/archlogs
on the independent file system /zfs1
. So the we have both the latest file, samqfs1.archiver.log
, and a recent backup, 20140324
:
root@solaris:~#dir
/zfs1/samqfs1_recovery/archivelogs
20140322 20140323 20140324 root@solaris:~#
Search the most recent copy of the archiver log for entries that were made after the recovery point was created. Use the command grep
"
time-date-expression
"
archiver-log
, where time-date-expression
is a regular expression that matches the date and time where you want to start searching and archiver-log
is the path and name of the archiver log copy that you are examining.
In the example, we lost the file system at 2:02 AM on March 4, 2014. The last recovery point file was made at 2:10 AM on March 3, 2014. So we search for archived files that were logged on March 3 or 4.
root@solaris:~#grep
"
^A 2014\/03\/[34]
"
/var/adm/samqfs1.archiver.log
When you find an entry for a backup copy of an unrestored file, note the path, name, file type, media type, and location information.
File types are listed as f
for regular files, R
for removable-media files, or S
for a data segment in a segmented file. The media type is a two-character code (see Appendix B).
To locate the backup copy, you need the volume serial number of the media volume that stores the copy. If the copy is stored on sequential-access media, such as magnetic tape, also note the hexadecimal value that represents the starting position of the archive (tar
) file. If the copy is stored on random-access media, such as archival disk, note the path and file name of the tar
file relative to the volume serial number. Finally, if the file is segmented, note the segment length.
In the example below, the archiver log entries show that the following files were archived after the last recovery point was created:
root@solaris:~#grep
"^A 2014\/03\/[34]"
/var/adm/samqfs1.archiver.log
A
2014/03/03 10:43:18li
VOL002
all.1111
.1 samqfs1 1053.3 69genfiles/hops
f
0 0A
2014/03/03 10:43:18li
VOL002
all.1111
.3 samqfs1 1051.1 104genfiles/anic
f
0 0A
2014/03/03 13:09:05li
VOL004
all.1212
.1 samqfs1 1535.2 1971genfiles/genA0
f
0 0A
2014/03/03 13:09:06li
VOL004
all.1212
.20 samqfs1 1534.2 1497genfiles/genA9
f
0 0A
2014/03/03 13:10:15li
VOL004
all.1212
.3f samqfs1 1533.2 6491genfiles/genA2
f
0 0A
2014/03/03 13:12:25li
VOL003
all.12
.5e samqfs1 1532.2 17717genfiles/genA13
f
0 0A
2014/03/03 13:12:28li
VOL003
all.12
.7d samqfs1 1531.2 14472genfiles/genA4
f
0 0A
2014/03/03 13:12:40li
VOL003
all.12
.9c samqfs1 1530.2 19971genfiles/genA45
f
0 0A
2014/03/03 21:49:15dk
DISKVOL1
/f2
all.1 2.2e9 samqfs1 1511.2 8971socfiles/spcC4
f
0 0A
2014/03/03 21:49:15dk
DISKVOL1
/f2
all.1 2.308 samqfs1 1510.2 7797spcfiles/spcC5
f
0 0A
2014/03/03 14:01:47li
VOL013
all.176a
.1 samqfs1 14.510485760
bf/dat011
/1
S
0 51A
2014/03/03 14:04:11li
VOL013
all.176a
.5002 samqfs1 15.510485760
bf/dat011
/2
S
0 51A
2014/03/03 14:06:24li
VOL013
all.11409aa4
.1 samqfs1 16.5184
bf/dat011
/
3 S 0 51A
2014/03/03 18:28:51 liVOL036
all.112d
.1 samqfs1 11731.1 89128448rf/rf81
f
0
210A
2013/08/23 18:28:51 liVOL034
all.115f
.0 samqfs1 11731.1 525271552rf/rf81
f
1
220 root@solaris:~#
We note the following information:
Eight regular (type f
) files are archived (A
) on LTO (li
) media: genfiles/
hops
and genfiles/
anic
at position 0x111
on volume VOL002
, genfiles/
genA0
, genfiles/
genA9
and genfiles/
genA2
at position 0x212
on volume VOL004
, and genfiles/
genA13
, genfiles/
genA4
, and genfiles/
genA45
at position 0x212
on volume VOL003
.
Two regular (type f
) files are archived (A
) on disk (dk
) media: spcfiles/
spcC4
and spcfiles/
spcC5
in archive file DISKVOL1
\f2
on volume DISKVOL1
.
One, three-part, segmented (type S
) file is archived on LTO (li
) media: bf/dat011
, in two segments starting at position 0x76a
and one segment starting at position 1409aa4
on volume VOL013
. Segment /1
is 10485760
bytes long, segment /2
is 10485622
bytes, and segment /3
is 184
bytes.
One, regular (type f
), volume overflow file archived (A
) on LTO (li
) media: rf/rf81
, starting at position 0x12d
on volume VOL036
and continuing at position 0x15f
on volume VOL034
.
For a full explanation of the fields in archiver log entries, see Appendix A, "Understanding the Archiver Log".
Repeat the search using any backup archive logs that were created after the recovery point file was created.
Archiver logs are rolled over frequently. So, if you retain multiple archiver log copies, you may be able to recover damaged files using archive copies that were made before the period covered by the current archiver log.
Given the media volume and the position of an archive (tar
) file on the media, restoring a missing or damaged files is simply a matter of accessing the tar
file and extracting the required data file. When the archive files reside on archival disk devices, this is simple, because the tar
files reside in randomly accessible directories under a file-system mount point. When the tar
file resides on high-capacity, sequential-access media like tape, however, there is an added complication: we cannot normally extract the required data file from the archive file until the latter is staged to a random-access disk device. Since archive files can be large, this can be time-consuming and awkward in a recovery situation. So the procedures below take advantage of the SAM-QFS command request
, which reads the archive files into memory and makes them available as if they were being read from disk.
Restore as many damaged and missing regular files as you can. For each file, proceed as follows:
Start by recovering regular files that do not span volumes. Use the procedure"Restore Lost and Damaged Regular Files".
Next, recover the segmented files. Use the procedure "Restore Lost and Damaged Segmented Files".
Then restore the regular files that do span volumes. Use the procedure "Restore Lost and Damaged Volume Overflow Files".
Once you have restored all missing and damaged files that have copies, re-enable archiving by removing wait
directives from the archiver.cmd
file and re-enable recycling by removing -ignore
parameters from the recycler.cmd
file.
The file system is as close to its original condition as possible. Files that are still damaged or missing cannot be recovered.
Once you have restored all missing and damaged files that have copies, go to "Restoring Archiving File Systems to Normal Operation".
If you must recover a file system directly from the archival media, without the assistance of a recovery point file, you can do so. You proceed as follows:
If you are trying to restore files from optical media, stop here and contact Oracle support services for assistance.
Disable network file system (NFS) sharing for the file system.
Disable archiving and recycling, using the method outlined in "Stopping Archiving and Recycling Processes".
Reserve a tape drive for the exclusive use of the recovery process. Use the command samcmd
unavail
drive-equipment-number
, where drive-equipment-number
is the equipment ordinal number assigned to the drive in the /etc/opt/SUNWsamfs/mcf
file.
The samcmd
unavail
command makes the drive unavailable to archiving, staging and releasing processes. In the example, we reserve drive 804
root@solaris:~#samcmd
unavail
804
root@solaris:~#
Copy the file /opt/SUNWsamfs/examples/tarback.sh
to an alternate location, such as /tmp
.
The tarback.sh
file is an executable script that restores files from a specified set of media volumes. The script runs the command star -n
against each archive (tar
) file on each volume. When a backup copy on tape has no corresponding file in the file system or when the copy on tape is newer than the corresponding file in the file system, star -n
restores the copy.
In the example, we copy the script to /tmp
:
root@solaris:~#cp
/opt/SUNWsamfs/examples/tarback.sh
/tmp/tarback.sh
root@solaris:~#
Open the copy of the tarback.sh
file in a text editor.
root@solaris:~#vi
/opt/SUNWsamfs/examples/tarback.sh
#!/bin/sh # script to reload files from SAMFS archive tapes STAR="/opt/SUNWsamfs/sbin/star" LOAD="/opt/SUNWsamfs/sbin/load" UNLOAD="/opt/SUNWsamfs/sbin/unload" EQ=28 TAPEDRIVE="/dev/rmt/3cbn" # BLOCKSIZE is in units of 512 bytes (e.g. 256 for 128K) BLOCKSIZE=256 MEDIATYPE="lt" VSN_LIST="VSNA VSNB VSNC VSNZ" ...
If the SAM-QFS utilities star
, load
, and unload
are installed in non-standard locations, edit the default command paths in the copy of the tarback.sh
file.
In the example, all utilities are installed in the default locations, so no edits are needed:
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh #!/bin/sh # script to reload files from SAMFS archive tapes STAR="/opt/SUNWsamfs/sbin/star" LOAD="/opt/SUNWsamfs/sbin/load" UNLOAD="/opt/SUNWsamfs/sbin/unload" ...
In the copy of the tarback.sh
file, locate the variable EQ
and set its value to the equipment ordinal number of the drive that you reserved for recovery use.
In the example, we set EQ=804
:
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh
#!/bin/sh
# script to reload files from SAMFS archive tapes
STAR="/opt/SUNWsamfs/sbin/star"
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
...
In the copy of the tarback.sh
file, locate the variable TAPEDRIVE
and set its value to the raw path to the device, enclosed in double quotation marks.
In the example, the raw path to device 804
is /dev/rmt/3cbn
:
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh
#!/bin/sh
# script to reload files from SAMFS archive tapes
STAR="/opt/SUNWsamfs/sbin/star"
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
...
In the copy of the tarback.sh
file, locate the variable BLOCKSIZE
and set its value to the number of 512-byte units in the desired block size.
In the example, we want a 256-kilobyte segment size for the LTO-4 drive. So we specify 512
:
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
...
In the copy of the tarback.sh
file, locate the variable MEDIATYPE
and set its value to the two-character media-type code that Appendix B lists for the type of media that the drive supports. Enclose the media type in double quotation marks.
In the example, we are using an LTO-4 drive. So we specify li
:
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
MEDIATYPE="lt"
...
In the copy of the tarback.sh
file, locate the variable VSN_LIST
and, as its value, supply a space-delimited list of the volume serial numbers (VSNs) of the tape volumes that might contain backup copies of your files, enclosed in double quotation marks.
In the example, we specify volumes VOL002
, VOL003
, VOL004
, VOL013
, VOL034
, and VOL036
:
EQ=804 TAPEDRIVE="/dev/rmt/3cbn" BLOCKSIZE=512 MEDIATYPE="lt"VSN_LIST="
VOL002
VOL003
VOL004
VOL013
VOL034
VOL036
"
...
Save the copy of the tarback.sh
file and close the editor.
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
MEDIATYPE="lt"
VSN_LIST="VOL002 VOL003 VOL004 VOL013 VOL034 VOL036"
...
:wq
root@solaris:~#
Execute the /tmp/tarback.sh
script.
root@solaris:~# /tmp/tarback.sh
For each restored file, recreate user and group ownership, modes, extended attributes, and access control lists (ACLs) as necessary.
The /tmp/tarback.sh
script cannot restore these types of metadata.
Once you have run the /tmp/tarback.sh
script and finished recovering files, go to "Restoring Archiving File Systems to Normal Operation".