Re: [Networker] Group wants to run a full?

Well via scripting you should move any non-recycleable save sets off of the
tape2 before you recycle it...

I use a script to suggest (for insertion) and to actually find and move save
sets off of tapes which have a miniscule amount of data left on them.

I've posted this before and this is obviously for UNIX/Linux...  Take away
the hash mark from infront of the nsrstage command to have it actually move
off data off of these tapes onto other tapes in the same media pool...

------  suggest_synoffsite.sh -----
#!/bin/sh

STARTPOOL=NAME_OF_YOUR_TAPE_POOL
# Identify tapes to check
TAPES=`mminfo -r volume -q
"pool=$STARTPOOL,ssrecycle,volretent>today,full,location=""`

# Check if TAPES exist...
if [ ! "$TAPES" ]; then
  exit
fi

space_used ()
{
  USED=`mminfo -r fragsize'(15)' -q volume=$1,\!ssrecycle | awk -e '{total =
total + $1} END {print total/1024/1024/1024}'`
}

get_pool ()
{
  POOL=`mminfo -r pool -q volume=$1`
}

get_non_expired_ssid ()
{
  NONEXPIREDSSID=`mminfo -r ssid,cloneid -xc/ -q volume=$1,!ssrecycle | sed
-e 1d`
}

get_totalsize ()
{
  TOTALSIZE=`mminfo -r totalsize -q ssid=$1`
}

# Scan through each tape and get the size
for TAPE in $TAPES; do
  space_used $TAPE
  if [ $USED -lt 20 ]; then
    get_pool $TAPE
    # echo $TAPE $USED $POOL
    if [ $POOL -eq "$STARTPOOL" ]; then
      # echo "Destaging from $POOL to $POOL"
      get_non_expired_ssid $TAPE
      if [ "$NONEXPIREDSSID" ]; then
        for SSID in $NONEXPIREDSSID; do
          get_totalsize $SSID
          if [ "$TOTALSIZE" -gt 200000000000 ]; then
            echo "\tSkipping $TAPE because $SSID ($TOTALSIZE) is over the
limit."
            continue
          fi
        done
        # nsrstage -b $POOL -m -S $NONEXPIREDSSID
        echo "$TAPE"
      fi
    fi
  fi
done

Alec

On Sun, Feb 28, 2010 at 3:36 PM, George Sinclair
<George.Sinclair AT noaa DOT gov>wrote:

> Davina Treiber wrote:
>
>> George Sinclair wrote:
>>
>>> I have a tape pool that I turned off indexing on (Store index
>>> entries=No). Also, selected the 'No index save' option for the group. I then
>>> ran a full on the group. It completed just dandy. I then ran an incremental
>>> estimate on the backup server as:
>>>
>>> savegrp -n -l incr group
>>>
>>> and it reports that no full backups of this save set were found in the
>>> mediadatabase; performing a full backup. However, I can query the media
>>> database, and it reports the save set (no spelling mistakes).
>>>
>>> Isn't an incremental based on the last media database entry, not the CFI?
>>> Something seems odd here:
>>>
>>>
>> Think about this a minute George.
>> Running an incremental requires that the server knows the details of each
>> file that was backed up in the full, thus you MUST have a CFI available. If
>> you turn off indexing you simply cannot do incrementals or level backups.
>>
>
> Well, I thought that the CFI was only used for recovers and that NW based
> its backup criteria on change of file status time (default) for the file, as
> in if it's change of file status time is more recent than the last time its
> save set (parent save set; e.g. /var for /var/file.txt) was backed up then
> it gets backed up; otherwise not. The date/time for the parent save set is
> contained in the media database, right? So if something as simple as the
> group, owner or even file permissions change, as opposed to content (mod
> time), then the file status time (inode info) changes, not mod time, but in
> either case, it could determine that it's more recent than the last time the
> related save set was backed up by checking the media database?
> clearly, there must be a flaw in my thinking, though?
>
>
>
>> Why would you do this anyway? You might save a miniscule amount of disk
>> space but disk is cheap these days. The saving is hardly worth it when you
>> consider the cost to your employer of your time to micro-manage this. If I
>> was you I would just turn the indexing back on and stop worrying about it.
>>
>
> This was just a test using a test pool. But this brings up a question,
> which I've outline below. The reason I wanted to exclude all indexing is
> because I plan to recycle this tape. If I do that, what happens if other
> 'legitimate' backups for this client (e.g. other NSR client resources/groups
> for this client) are also backing up this same save set? Once I remove the
> volume, what if there was a later incremental back up of that same saveset
> from some other pool, client resource? How could I recover the whole thing
> since it based its incremental on the one before and the one before that ...
> all the way back to the previous full. If you remove one somewhere in
> between then how could you rebuild the whole thing? Keeping it non-indexed
> seemed like a good way to avoid compromising the other backups of this save
> set? Not sure if I'm explaining it correctly, but maybe my understanding
> here is wrong?
>
> Let's say I have two NSR client resources for ralph, both members of two
> different groups, each a member of two separate pools. Both clients have the
> following save set:
>
> ralph:/home/junk
>
> Let's suppose the backups go like this:
>
> ralph (1 of 2) level full vol TP1
> ralph (1 of 2) level incr vol TP1
> ralph (1 of 2) level incr vol TP1
> ralph (2 of 2) level full vol TP2
> ralph (2 of 2) level incr vol TP2
> ralph (1 of 2) level incr vol TP1
>
> If I remove volume TP2, I loose all the media database entries for TP2, so
> how can my last incr from TP1 still be valid if it was based on what changed
> since the previous one for TP2?
>
> George
>
>
>
>> To sign off this list, send email to listserv AT listserv.temple DOT edu and
>> type "signoff networker" in the body of the email. Please write to
>> networker-request AT listserv.temple DOT edu if you have any problems with 
>> this
>> list. You can access the archives at
>> http://listserv.temple.edu/archives/networker.html or
>> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>>
>>
>
> --
> George Sinclair
> Voice: (301) 713-3284 x210
> - The preceding message is personal and does not reflect any official or
> unofficial position of the United States Department of Commerce -
> - Any opinions expressed in this message are NOT those of the US Govt. -
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and 
> type
> "signoff networker" in the body of the email. Please write to
> networker-request AT listserv.temple DOT edu if you have any problems with 
> this
> list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER