ADSM-L

serious volume problem

2015-10-04 17:46:05
Subject: serious volume problem
From: Henk ten Have [mailto:hthta AT SARA DOT NL]
To: ADSM-L AT VM.MARIST DOT EDU
I think a have a serious problem. Well, actually I don't think so, but
I'am sure.

A volume (U00020) is defined to a storagepool (UNITEPOOL) and is
used for backup's. After a while, Space reclamation started for this
volume:

03/29/99   09:33:53  ANR1040I Space reclamation started for volume U00020,
                      storage pool UNITEPOOL (process number 597).
03/29/99   09:33:53  ANR1044I Removable volume U00020 is required for space
                      reclamation.
03/29/99   09:33:53  ANR8324I 3590 volume U00020 is expected to be mounted
                      (R/O).
03/29/99   09:33:53  ANR1142I Moving data for collocation cluster 1 of 1 on
                      volume U00020.
03/29/99   12:28:20  ANR1175W Volume U00020 contains files which could not
be
                      reclaimed.
03/29/99   12:28:20  ANR1410W Access mode for volume U00020 now set to
                      "unavailable".
03/29/99   12:28:20  ANR1041I Space reclamation ended for volume U00020.

Well, after the space reclamation ended and the volume is set to
"unavailable",
it is disappeared from the storagepool:

adsm> q vol U*
....
U00018                    UNITEPOOL    3494-3590         0.0    0.0  Pending
U00019                    UNITEPOOL    3494-3590         0.0    0.0  Pending
U00021                    UNITEPOOL    3494-3590    14,920.0   68.1    Full
U00022                    UNITEPOOL    3494-3590         0.0    0.0  Pending
....

Every morning at 09:00, a backup db started, which should use only
scratch volumes. Well, at least, this is the way it works for a long
time :-(

SURPRISE:
Private volume U00020 is used:

03/30/99   09:00:24  ANR2750I Starting scheduled command BACKUP_DB ( backup
db
                      devclass=3494-3590 type=full ).
03/30/99   09:00:24  ANR2017I Administrator ADMIN issued command: BACKUP DB
                      devclass=3494-3590 type=full
03/30/99   09:00:24  ANR0984I Process 628 for DATABASE BACKUP started in the
                      BACKGROUND at 09:00:24.
03/30/99   09:00:24  ANR2280I Full database backup started as process 628.
03/30/99   09:00:24  ANR2280I Full database backup started as process 628.
03/30/99   09:00:24  ANR2753I (BACKUP_DB):ANR2280I Full database backup
started
                      as
03/30/99   09:00:24  ANR2753I (BACKUP_DB):process 628.
03/30/99   09:00:24  ANR2756I Scheduled command BACKUP_DB started
successfully.
03/30/99   09:01:05  ANR8337I 3590 volume U00020 mounted in drive 3590-2
                      (/dev/rmt2).
03/30/99   09:01:07  ANR1360I Output volume U00020 opened (sequence number
1).
.....
.....
03/30/99   09:52:40  ANR4554I Backed up 2292528 of 2326863 database pages.
03/30/99   09:53:10  ANR4554I Backed up 2316736 of 2326863 database pages.
03/30/99   09:53:31  ANR1361I Output volume U00020 closed.
03/30/99   09:53:33  ANR8336I Verifying label of 3590 volume U00020 in drive
                      3590-2 (/dev/rmt2).
03/30/99   09:53:36  ANR4550I Full database backup (process 628) complete,
                      2326863 pages copied.
03/30/99   09:53:36  ANR0985I Process 628 for DATABASE BACKUP running in the
                      BACKGROUND completed with completion state SUCCESS at
                      09:53:36.
03/30/99   09:54:02  ANR8468I 3590 volume U00020 dismounted from drive
3590-2
                      (/dev/rmt2) in library 3494LIB.

And volume U00020 suddenly appear in the libvol as Private/DbBackup:

adsm> q libvol * U*
3494LIB         U00018         Private              Data
3494LIB         U00019         Private              Data
3494LIB         U00020         Private              DbBackup
3494LIB         U00021         Private              Data
3494LIB         U00022         Private              Data

So, the backup-data from volume U00020 is gone for ever.

And this is not the only volume which is destroyed this way.

Questions:

1. Why are the volumes disappear from the storagepool?
2. Why is backup db using private volumes?

Anyone any clues?

Cheers,
Henk ten Have ( ADSM Server 3.1.2.15 on AIX 4.2.1.0)
<Prev in Thread] Current Thread [Next in Thread>