sparse files after recover from make_tape_recovery

[Ekkehard Schulz]

hp-ux 11.11
ignite 5.1 (know it is not the latest version)

I have recovered the system from a tape created by make_tape_recovery (including the whole vg00). In the origin system I had two Versant database files each 2000MB, but mostly empty. After recovery I check the system with bdf and was very astonished. In one volume group I missed approx. 3,4 GB data. First I thought that either backup or restore had been broken, but all files had been restored.
As indicated the solution are the database files. These files are shown by ll with its original length (2000MB), but df/bdf shows only the disk space currently occupied (some MB).

To save space and time during backup I can accept this Ignite behaviour (large, but empty files). But after restore I would expect to have the same system state as before.

It can be dangerous to use the disk space in this filesystem for other files where the disk space is rather reserved for the database.

My question: Is there a way to avoid this behaviour of Ignite ?

[Pete Randall]

You can avoid this by first - only backing up vg00 and second - by keeping your data in separate vg's other than vg00. Ignite is not designed to back up your data and you should be using conventional backup methods to back up and recover your data separate from your root vg.


Pete

[Steven E. Protter]

You probably just tried to back up some open database files. Those files will be useless on recovery anyway.

Ignite is very good a system backups and vry picky about everything else.

It is useful for database backups only if those databases are shut down when the Ignite tape is made.

SEP

[Bill Hassell]

As mentioned, database files should not be part of VG00 and make_tape_recovery should not be used for backup, only for disaster recovery, ie, loss of the boot disk(s). Many database programs do indeed create sparse files and disk space management can be a problem if these files are shared with other, unrelated files. The database may need to grow and when the filesystem is full, the database will crash or at least give out a lot of error messages.

If your database has the option of allocating all the space assigned for each file, use that to build the files. The other choice is to backup the files with something like tar or cpio (for files 2Gb and smaller), then restore the files. Sparse files will be serially read by tar/cpio and all the unoccupied space will be saved as a series of nulls. When restored, the nulls will be left intact and the full space will be used. A related command is: prealloc

[Ekkehard Schulz]

Thank you for the first replies.

There are two aspects in your answers.

a) Usage of Ignite
b) the sparse file problem

ad a)

We have a server system which is delivered to several customers. The system consists of HP-UX, a lot of 3PP and our applications. The setup takes 1-2 days. After a quick check our support staff shuts down the system into single user mode and runs the make_tape_recovery to have a complete backup of the whole system. The tape(s) can be stored on safe place at customer site to have the possibility for a desaster recovery.
Therefore I think make_tape_recovery is a simple tool with enough power to fullfill this task.

ad b)

1. Versant does not create sparse files. The database files are normal files, the "sparse aspect" occurs only after restore.

2. Steven, you are right. The database was not really down when the tape was created.
But at this moment no applications were running against the db. In contrast to Oracle the Versant database can be started from the recovered (open) files, check consistency command runs without error, all objects can be displayed.

Therefore I don't believe that the sparse effect is in relation to "open" database files. It must be a feature (or error ???) of
Ignite restore.
I would guess each other big file with almost nulls is handled in the same way.

[Michael Roberts_3 · Accepted solution]

Ignite uses pax to create the archive. it does not have it's own archiving method and is only as capable as pax.

Can you try this experiment?

# pack up the file similar to how Ignite will
pax -wf - VersantFile | gzip - > VersantFile_pax.gz

# check the size the archive thinks the file
# is.
gzcat VersantFile_pax.gz | pax -tvf -

# extract the file into a different name and
# check the size
gzcat VersantFile_pax.gz | pax -rif -
rename VersantFile? fooBar

ll fooBar
du fooBar

[A. Clay Stephenson]

This is normal behavior for the underlying pax command. On restore, when pax sees a long string of ASCII NUL's (I have no idea of the exact trigger level) it does not write() but instead does an lseek() to the next non-NUL offset and resumes writing. The restore really has no idea of the "true" size of the file because when the file was read all the "holes" were simply filled with ASCII NUL's completely invisible to the read().

If you stop and think about this for a moment this is really the only safe way for Ignite to work. Consider the case where intentionally sparse files were used and indeed the filesystem was overcommited. If sparse files were filled-in on the restore then the filesystem would fill up and the Ignite would fail. I suppose it would be nice if it were possible to spot sparse files but that would change the behavior of the read() system call and I sure ain't ready for the problems that would cause.

You are correct that the "problem" has nothing to do with databases - open or closed. This is simply an artifact of the way the read() system call works to make sparse files invisible.

As the others have suggested. You should rerally use Ignite for vg00 and the remainder of the restore (if even necessary) should be part of your regular backup and restore.

[Ekkehard Schulz]

Hello, thanks for your answers.

Michael, here the results of the tests.

# ll system.orig
-rw------- 1 root sys 2097152000 Nov 24 09:32 system.orig
# du -k system.orig
2048008 system.orig

# pax -wf - system.orig | gzip - > system.pax.gz

# gzcat system.pax.gz | pax -tvf -
USTAR format archive
-rw------- 0 root sys 2097152000 Nov 24 09:32 system.orig
# gzcat system.pax.gz | pax -rif -
rename system.orig? xxx
# ll xxx
-rw------- 1 root sys 2097152000 Nov 24 09:32 xxx
# du -k xxx
6134 xxx

It is really a nice mechanism to save disk space. But seriously spoken, knowing this behaviour I'm able to document it to avoid error messages like
"Help, help after recovery from the Ignite tape I miss XXX GB of data !!!".

Thanks again for your help.

[John P. Kole]

How to convert a file from Sparse to NonSparse:


Step 1) Create the sparse file:
-----------------------------------------
# rm -f SparseDB
# touch SparseDB
# perl -e '$f="SparseDB";syscall(129,$f,0xf00000)'
# ls -al SparseDB
-rw-rw-rw- 1 kole users 15728640 Nov 24 10:36 SparseDB
# du -sk SparseDB
0 SparseDB

Step 2) Now use /usr/bin/cp to convert from Sparse to not NonSparse:
-----------------------------------------------------------------------------------------------
# /usr/bin/cp -p SparseDB NonSparseDB
# du -sk SparseDB NonSparseDB
0 SparseDB
15360 NonSparseDB