ADSM-L

FW: ADSM and UNIX filesystems

1998-01-15 08:16:00
Subject: FW: ADSM and UNIX filesystems
From: "Sanders, David" <DSanders AT INTERNAL.MASSMUTUAL DOT COM>
Date: Thu, 15 Jan 1998 08:16:00 -0500
This is a forwarded mailing from one of our users,,,

> -----Original Message-----
> From: Anderson, John
> Sent: Thursday, January 15, 1998 7:52 AM
> To:   Sanders, David
> Subject:      ADSM and UNIX filesystems
>
> Dave,
>
> Here's the problem:
>
> UNIX assigns disk space for files in chunks called FILESYSTEMS.
> Filesystems are "mounted" onto directories, and are used primarily for
> a couple of reasons:
>
>       * filesystems can only expand to their own limits (sort of like
> a PDS ... my files can't impact the space for your files)
>
>       * some systems have limitations on the size of filesystems (e.g.
> 4GB) which force you to have multiple filesystems to provide
> sufficient space for files
>
> ADSM makes a FILESPACE for each filesystem when it backs up a system.
> Now, here's the scenario we ran into, greatly simplified:
>
> A UNIX system has two filesystems, mounted on directories /dir1 and
> /dir1/dir2.  ADSM creates two filespaces, /dir1 and /dir1/dir2.  The
> following items become true:
>
>       * the file "/dir1/file1" is in filesystem and filespace "/dir1"
>       * the file "/dir1/dir2/file2" is in filesystem and filespace
> "/dir1/dir2"
>       * the file "/dir1/dir3/file3" is in filesystem and filespace
> "/dir1"
>       * the file "/dir1/dir2/dir4/file4" is in filesystem and
> filespace "/dir1/dir2"
>       * etc.
>
> At some point we decide on the UNIX system that we no longer need a
> separate filesystem "/dir1/dir2," so we move all of its files into the
> "/dir1" filesystem (probably enlarging that filesystem at the same
> time) and delete the "/dir1/dir2" filesystem.  From this point on, the
> above example files would all be contained in the filesystem and
> filespace "/dir1."  NOTE that ADSM considers those files to all be in
> the "/dir1" filespace FOR BACKUP PURPOSES ONLY.
>
> NOW HERE'S THE PROBLEM:
>
> ADSM never forgets unless you tell it to ... which means that the
> "/dir1/dir2" filespace is still present in its archives.  Someone
> deletes "/dir1/dir2/file2" and needs to have it restored.  I go into
> the dsm interface and do a Restore by Filename and enter
> "/dir1/dir2/file2."  ADSM comes back and shows me the ACTIVE file,
> which is the LAST version which existed prior to the deletion of the
> "/dir1/dir2" filesystem!  In order to get at the current version of
> this file, I have to specify "/dir1/*" and "List all subdirectories,"
> then sort through the potentially enormous output to find the file I
> need.
>
> WHAT ADSM SHOULD DO:
>
> Ideally, ADSM will recognize during a backup that a filesystem has
> been deleted, and will initiate a background administrative task on
> the ADSM server that will move all file definitions from that
> filespace into the next "higher" filespace, and delete the definition
> for the defunct filespace.
>
> As a workaround, there should at least be an administrative option
> that will allow us to manually indicate that a filespace should be
> deleted and all of its file definitions moved into another specified
> filespace.
>
>
> ===================================
> John M. Anderson                      MassMutual Life Insurance
> Technical Specialist                                  1295 State
> Street
> AIX and HP-UX Support            Springfield, MA 01111-0001
> janderson AT massmutual DOT com                       (413) 744-2268
>
<Prev in Thread] Current Thread [Next in Thread>