Varying backup times with DAT drive

[Peter Harding]

Hi,

I have a problem with backups on a RS/6000 J40 running AIX 4.3. We are
trying to backup approx. 8GB of data on a Seagate Scorpion 20/40GB
tape drive. Some nights it runs OK and completes in 1hr 10mins, other
nights it will fail after 2hrs 15mins asking for a 2nd tape. I have
tried both cpio and tar with the same results. The tape drive settings
have been set as per Seagate's instruction (and dip switches) as
follows:

rs6000> lsattr -El rmt1
mode yes Use DEVICE BUFFERS during writes True
block_size 1024 BLOCK size (0=variable length) True
extfm yes Use EXTENDED file marks True
res_support no RESERVE/RELEASE support True
var_block_size 0 BLOCK SIZE for variable length support True
density_set_1 140 DENSITY setting #1 True
density_set_2 0 DENSITY setting #2 True
delay 45 Set delay after a FAILED command True
rwtimeout 900 Set timeout for the READ or WRITE command True
ret_error no RETURN error on tape change or reset True

The data slightly increases in size each day, but there is no big jump
in size (increase or decrese), so I can't see why it will fit on the
tape one night, but another night it will ask for a 2nd tape.

Any ideas?

[Andreas Schulze]

"Peter Harding" <peterharding@yahoo.com> schrieb im Newsbeitrag
news:bf403c5e.0309100241.5907f6cf@posting.google.c om...

> Hi,
>
> I have a problem with backups on a RS/6000 J40 running AIX 4.3. We are
> trying to backup approx. 8GB of data on a Seagate Scorpion 20/40GB
> tape drive. Some nights it runs OK and completes in 1hr 10mins, other
> nights it will fail after 2hrs 15mins asking for a 2nd tape. I have
> tried both cpio and tar with the same results. The tape drive settings
> have been set as per Seagate's instruction (and dip switches) as
> follows:
>
> rs6000> lsattr -El rmt1
> mode yes Use DEVICE BUFFERS during writes True
> block_size 1024 BLOCK size (0=variable length) True
> extfm yes Use EXTENDED file marks True
> res_support no RESERVE/RELEASE support True
> var_block_size 0 BLOCK SIZE for variable length support True
> density_set_1 140 DENSITY setting #1 True
> density_set_2 0 DENSITY setting #2 True
> delay 45 Set delay after a FAILED command True
> rwtimeout 900 Set timeout for the READ or WRITE command True
> ret_error no RETURN error on tape change or reset True
>
> The data slightly increases in size each day, but there is no big jump
> in size (increase or decrese), so I can't see why it will fit on the
> tape one night, but another night it will ask for a 2nd tape.
>
> Any ideas?

Hallo Peter,

please supply more information:
1) What is/are the exact command/s you used?
2) Do you enter them by hand or through a script?
3) If script controlled, are you using cron to run the script?
4) If using cron: are there other jobs running at the same time? Especially
tools which clean up filesystems while backing up e.g. skulker?
5) Are the tapes physically identical? (Same DDS Level)

Regards,
Andreas

[Steve Nottingham]

[email]peterharding@yahoo.com[/email] (Peter Harding) wrote in message news:<bf403c5e.0309100241.5907f6cf@posting.google. com>...

> Hi,
>
> I have a problem with backups on a RS/6000 J40 running AIX 4.3. We are
> trying to backup approx. 8GB of data on a Seagate Scorpion 20/40GB
> tape drive. Some nights it runs OK and completes in 1hr 10mins, other
> nights it will fail after 2hrs 15mins asking for a 2nd tape. I have
> tried both cpio and tar with the same results. The tape drive settings
> have been set as per Seagate's instruction (and dip switches) as
> follows:
>
> rs6000> lsattr -El rmt1
> mode yes Use DEVICE BUFFERS during writes True
> block_size 1024 BLOCK size (0=variable length) True
> extfm yes Use EXTENDED file marks True
> res_support no RESERVE/RELEASE support True
> var_block_size 0 BLOCK SIZE for variable length support True
> density_set_1 140 DENSITY setting #1 True
> density_set_2 0 DENSITY setting #2 True
> delay 45 Set delay after a FAILED command True
> rwtimeout 900 Set timeout for the READ or WRITE command True
> ret_error no RETURN error on tape change or reset True
>
> The data slightly increases in size each day, but there is no big jump
> in size (increase or decrese), so I can't see why it will fit on the
> tape one night, but another night it will ask for a 2nd tape.
>
> Any ideas?

What command are you using to backup the data ?

Steve

[Peter Harding]

Hi Andreas (and Steve), here are some answers:

> please supply more information:
> 1) What is/are the exact command/s you used?

cd /live
tar -cvf /dev/rmt1 *
(also tried "find . -print | cpio -ocvB > /dev/rmt1)

> 2) Do you enter them by hand or through a script?

I have tried both, but currently it's running via a script.

> 3) If script controlled, are you using cron to run the script?

Yes, via cron.

> 4) If using cron: are there other jobs running at the same time? Especially
> tools which clean up filesystems while backing up e.g. skulker?

Yes, skulker kicks in 1 hour after the backup starts. I can understand
why this would slow the backup up, but why do I struggle to get 8GB on
a 20GB tape?

> 5) Are the tapes physically identical? (Same DDS Level)

Yes, they're all DDS-4.

Thanks, Pete.

[Andreas Schulze]

"Peter Harding" <peterharding@yahoo.com> schrieb im Newsbeitrag
news:bf403c5e.0309110647.fa0c9c0@posting.google.co m...

> Hi Andreas (and Steve), here are some answers:
>

> > please supply more information:
> > 1) What is/are the exact command/s you used?

> cd /live
> tar -cvf /dev/rmt1 *
> (also tried "find . -print | cpio -ocvB > /dev/rmt1)

> > 2) Do you enter them by hand or through a script?

> I have tried both, but currently it's running via a script.

> > 3) If script controlled, are you using cron to run the script?

> Yes, via cron.

> > 4) If using cron: are there other jobs running at the same time?

Especially

> > tools which clean up filesystems while backing up e.g. skulker?

> Yes, skulker kicks in 1 hour after the backup starts. I can understand
> why this would slow the backup up, but why do I struggle to get 8GB on
> a 20GB tape?

> > 5) Are the tapes physically identical? (Same DDS Level)

> Yes, they're all DDS-4.
>
> Thanks, Pete.

Hallo Pete,

from your answers I now suspect that the problem might lay in the data
itself. Blind guess, because you tar about 8 Gig per night: do you backup a
database (tablespaces of a db)? Then the following might apply:
[quote from man restore]
About Sparse Files

Operating system filesystems, files containing long strings of NULLs can be
stored much more efficiently than other files. To be specific, if a string
of
NULLs spans an entire allocation block, that whole block is not stored on
disk
at all. Files where one or more blocks are omitted in this way are called
sparse
files. The missing blocks are also known as holes.

Note :Sparse files are not the same as compressed files. Sparse files
are
exactly the same as their non-sparse equivalents when they are read.

Sparse files are generally created by database applications. Since whenever
a
database file is created it is formatted with NULLs. These fragments may be
either filled with allocated or unallocated NULLs.
[End quote man restore]
Now put this information in relationship to tar.
[quote from man tar]
tar does not preserve the sparse nature of any file that is sparsely
allocated. Any file that was originally sparse before the restoration
will have all space allocated within the filesystem for the size of the
file.
[End quote from man tar]

In other words: in case you tar sparse files tar might blow up the files
size because it really allocates "all space allocated withen the filesystem
[where originally a string of NULLs spaned entire allocation blocks before]
for the size of the file.
In this case the solution is to use backup and restore to backup your data.
Both progs keep the 'sparseness' of your files (plus advanced features of
AIX jfs).

HTH,
Andreas

[Olaf Rogalsky]

Andreas Schulze wrote:

> In other words: in case you tar sparse files tar might blow up the files
> size because it really allocates "all space allocated withen the filesystem
> [where originally a string of NULLs spaned entire allocation blocks before]
> for the size of the file.
> In this case the solution is to use backup and restore to backup your data.
> Both progs keep the 'sparseness' of your files (plus advanced features of
> AIX jfs).

Or use gnutar with the "--sparse" option.

--
+----------------------------------------------------------------------+
I Dr. Olaf Rogalsky Institut f. Theo. Physik I I
I Tel.: 09131 8528440 Univ. Erlangen-Nuernberg I
I Fax.: 09131 8528444 Staudtstrasse 7 B3 I
I [email]rogalsky@theorie1.physik.uni-erlangen.de[/email] D-91058 Erlangen I
+----------------------------------------------------------------------+