Backup Central

Can someone give me a braincheck on this?

If I do:

# mminfo -ar 'nsavetime,sscreate(22)' -c jupiter -N /dir1 -q '!ssrecycle'

I see a listing thus :

save time ss created
1264829064 01/29/10 23:24:24
1265094026 02/02/10 01:02:54
1265180427 02/03/10 01:02:06
1265266822 02/04/10 01:02:07
1265353207 02/05/10 01:00:05
1265434114 02/05/10 23:28:35

...and so on, up to the last backup. These should be all the browseable /
recoverable backups for "/dir1" on "jupiter" currently in the database (we
keep our browse and recovery policies equal).

Therefore, running nsrinfo with one of the 'nsavetime' values like this :

# nsrinfo -t 1264829064 jupiter

...spews output thus :

/dir1/lost+found/
/dir1/.profile
/dir1/subdir2/subdir3/more_subdirs/install
/dir1/subdir2/subdir3/more_subdirs/installer
/dir1/subdir2/subdir3/more_subdirs/locks/
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-19-55PM.log
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-59-39-PM.log
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-59-39-PM.out
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-59-39-PM.err

...for thousands of lines. This output should be a listing of every file
backed up for that given savetime, right? And, therefore, if I go through
all active savetimes and a given file never shows up, then it was never
backed up.

I'm just a bit brain-weary this afternoon and would like to know I'm not
overlooking something obvious.

Thanks!



The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please delete the message and immediately contact the sender if you have received this message in error.


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

In regard to: [Networker] Sanity check on mminfo / nsrinfo usage, Len...:

Therefore, running nsrinfo with one of the 'nsavetime' values like this :

# nsrinfo -t 1264829064 jupiter

...spews output thus :

/dir1/lost+found/
/dir1/.profile
/dir1/subdir2/subdir3/more_subdirs/install
/dir1/subdir2/subdir3/more_subdirs/installer
/dir1/subdir2/subdir3/more_subdirs/locks/
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-19-55PM.log
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-59-39-PM.log
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-59-39-PM.out
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-59-39-PM.err

...for thousands of lines. This output should be a listing of every file
backed up for that given savetime, right? And, therefore, if I go through
all active savetimes and a given file never shows up, then it was never
backed up.

That's correct. If your client were configured to not save index entries
then this wouldn't work. Also, we've discovered that with some client
types (NetWare) what nsrinfo reports on Linux/UNIX doesn't actually match
what the clients notion of file names are. I think this has to do with
the "namespace" feature of NetWare, but I honestly don't completely
understand it.

Tim
--
Tim Mooney Tim.Mooney < at > ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Len Philpot wrote:
Can someone give me a braincheck on this?

If I do:

# mminfo -ar 'nsavetime,sscreate(22)' -c jupiter -N /dir1 -q '!ssrecycle'

I see a listing thus :

save time ss created
1264829064 01/29/10 23:24:24
1265094026 02/02/10 01:02:54
1265180427 02/03/10 01:02:06
1265266822 02/04/10 01:02:07
1265353207 02/05/10 01:00:05
1265434114 02/05/10 23:28:35

...and so on, up to the last backup. These should be all the browseable /
recoverable backups for "/dir1" on "jupiter" currently in the database (we
keep our browse and recovery policies equal).

Therefore, running nsrinfo with one of the 'nsavetime' values like this :

# nsrinfo -t 1264829064 jupiter

...spews output thus :

/dir1/lost+found/
/dir1/.profile
/dir1/subdir2/subdir3/more_subdirs/install
/dir1/subdir2/subdir3/more_subdirs/installer
/dir1/subdir2/subdir3/more_subdirs/locks/
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-19-55PM.log
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-59-39-PM.log
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-59-39-PM.out
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-59-39-PM.err

...for thousands of lines. This output should be a listing of every file
backed up for that given savetime, right? And, therefore, if I go through
all active savetimes and a given file never shows up, then it was never
backed up.

Yes, if the file was not in any of the save sets then it wasn't backed
up. Were all these save sets full backups? If some were incremental or
level backups you might not see the file you were looking for anyway in
some of them.


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

måndag 08 mars 2010 23:40:16 skrev Len Philpot:
Can someone give me a braincheck on this?

If I do:

# mminfo -ar 'nsavetime,sscreate(22)' -c jupiter -N /dir1 -q '!ssrecycle'

I see a listing thus :

save time ss created
1264829064 01/29/10 23:24:24
1265094026 02/02/10 01:02:54
1265180427 02/03/10 01:02:06
1265266822 02/04/10 01:02:07
1265353207 02/05/10 01:00:05
1265434114 02/05/10 23:28:35

...and so on, up to the last backup. These should be all the browseable /
recoverable backups for "/dir1" on "jupiter" currently in the database (we
keep our browse and recovery policies equal).

Therefore, running nsrinfo with one of the 'nsavetime' values like this :

# nsrinfo -t 1264829064 jupiter

...spews output thus :

/dir1/lost+found/
/dir1/.profile
/dir1/subdir2/subdir3/more_subdirs/install
/dir1/subdir2/subdir3/more_subdirs/installer
/dir1/subdir2/subdir3/more_subdirs/locks/
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-19-55PM.log
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-59-39-PM.log
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-59-39-PM.out
/dir1/subdir2/subdir3/more_subdirs/logs/2007-01-05_03-59-39-PM.err

...for thousands of lines. This output should be a listing of every file
backed up for that given savetime, right? And, therefore, if I go through
all active savetimes and a given file never shows up, then it was never
backed up.

I'm just a bit brain-weary this afternoon and would like to know I'm not
overlooking something obvious.

If you are looking for a certain file only, it is probably easier to use
nsrinfo -N "filename" "client name" directly. Should give you a list of all
versions in the index database of that file.
It is case sensitive though...

Best
Dag


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Dag Nygren <dag < at > newtech.fi> wrote on 03/09/2010 03:12:59 AM:

If you are looking for a certain file only, it is probably easier to use

nsrinfo -N "filename" "client name" directly. Should give you a list of
all
versions in the index database of that file.
It is case sensitive though...

Thanks for the replies; I was out of town much of last week, hence my
delay in acknowledging them.

The specific request that triggered this was for files of unknown specific
name and/or case. That is, the requestor said they started with xyz*, but
didn't know if it was xyz*, XYZ*, XyZ*, etc. So it was simplest to just
list everything and egrep -i for the patterns.

Thanks again.


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER