CLEANING IMAGES

[abu_jaman]

Hi,

My master server root file system is getting filled up.

/dev/md/dsk/d10      10633036 8382014 2144692    80%    /
/devices                   0       0       0     0%    /devices
ctfs                       0       0       0     0%    /system/contract
proc                       0       0       0     0%    /proc
mnttab                     0       0       0     0%    /etc/mnttab
swap                 14192960    1368 14191592     1%    /etc/svc/volatile
objfs                      0       0       0     0%    /system/object
/platform/sun4u-us3/lib/libc_psr/libc_psr_hwcap1.so.1
                     10633036 8382014 2144692    80%    /platform/sun4u-us3/lib/libc_psr.so.1
/platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap1.so.1
                     10633036 8382014 2144692    80%    /platform/sun4u-us3/lib/sparcv9/libc_psr.so.1
fd                         0       0       0     0%    /dev/fd
swap                 14191696     104 14191592     1%    /tmp
swap                 14191656      64 14191592     1%    /var/run
/dev/md/dsk/d30      51637959 43201905 7919675    85%    /opt
I have found out that  images are occupying most of the spaces. Can i delete images to retrieve the disk spaces. We are in Solaris 10 and using Veritas 6.5

[ebodykid]

we just ended up presenting up some more san space, moved all of the images there and symlinked the images dir to the new location.  We also did the same for the staging area for our hot catalog backups as that would fill up the space when it ran as well.

[sunbkpsrv1]$pwd
/usr/openv/netbackup/db

lrwxrwxrwx   1 root     other         20 Aug 13 17:08 images -> /nbimages/linkimages

however just be VERY careful if you do this that the images can be seen properly by netbackup when it starts up, otherwise when it runs an image cleanup it will expire all of your media and move them back into the scratch pool.  In 6.5.4 they added a db_marker.txt file so that if netbackup doesnt see that file in the directory, it won't start up.  This was to prevent netbackup from doing what i described earlier, if for some reason the images were not accessible.  I would caution you to only do this if you know what you are doing, or with the help of support, as doing it wrong would cause a nightmare..

[Sriram]

You should never delete the images.  Check and expire the images that you don't want.

BTW where is your netbackup installed here.  I'm not able to see /usr/openv here.  Is that truncated here ?

As a remedy not to fill up your root file system with imge files do this:

Create a new file system

Create a soft link to point /usr/openv/netbackup/db to the new file system. something like this:

lrwxrwxrwx   1 root     other         11 Jan 22  2009 db -> /nbudata/db

Now this will eliminate root file system getting filled up which will save a possible server crash

[Andy_Welburn]

You could look at catalog compression if you haven't already got it set - in the GUI under NetBackup Management/Host Properties/Master Servers/master server/Global Attributes, tick the "Compress catalog interval" box & set the number of days after which you want the images compressing. Start slowly though. If your catalog goes back 1 year, set it to 320 or something so that it only compresses 45 days of images (it does this during image cleanup by the way - so this will take longer initially which is why you should start slowly). Then drop it in increments until you are at the level you are comfortable with. Please be aware though that checking for restores involving these compressed images will take a little longer as the application needs to uncompress them first.

You may also want to look at moving the image database at some point: DOCUMENTATION: How to move the image catalog on a UNIX Server

Moving the log files may also be an option:

DOCUMENTATION: Best Practice recommendations for enabling and gathering Veritas NetBackup (tm) 6.0 ...
DOCUMENTATION: How to configure Veritas NetBackup (tm) 6.x to write unified log files to a different...
DOCUMENTATION: How to configure automatic cleanup and recycling of unified log files with Veritas Ne...