Take the number (e.g. 092342342) and use bpdbm -ctime 092342342. This will
return the day and time of the backup.
Patrick Whelan
Senior Consultant
VERITAS ECS
[NBU (with extensions) and Storage Migrator for UNIX]
pwhelan AT veritas DOT com
"Of course this is just my opinion, I could be wrong." - Dennis Miller
"Stoicism is the wisdom of madness and cynicism the madness of wisdom" -
Bergen Evans
"Talent is like money; you don't have to have some to talk about it." -
Jules Renard
-----Original Message-----
From: W. Curtis Preston [mailto:curtis AT backupcentral DOT
com]
Sent: Saturday, June 23, 2001 8:04 AM
To: petes AT convergentdata DOT net;
veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Decode number in index name
This answer is long, but I think you'll really benefit if
you read on. I
don't know why I've never posted this before...
The format you're looking for is:
clientname_starttime
Clientname = name of the client that was backed up
Starttime = time (in seconds since the epoch) of the
SUCCESSFULL start time
of the backup
If elvis' backup starts at 092342342, fails, then gets
successfully retried
at 092342567, the backup id will be:
elvis_092342567
Here's the real question:
=============================================================
How do you figure out what the start time is for a given
job,
so you can use it to calculate the image ID?
=============================================================
You can get the start time from the "bpdbjobs -report
-all_columns" output.
First, we'll start with the somewhat-documented format of
the bpdbjobs
-report -all_columns output:
jobid,jobtype,state,status,class,schedule,client,server,started,elapsed,ende
d,stunit,try,operation,kbytes,files,pathlastwritten,percent,jobpid,owner,sub
type,classtype,schedule_type,priority,group,masterserver,retentionunits,rete
ntionperiod,compression,kbyteslastwritten,fileslastwritten,filelistcount,[fi
les]...,trycount,[trypid,trystunit,tryserver,trystarted,tryelapsed,tryended,
trystatus,trystatusdescription,trystatuscount,[trystatuslines]...,trybyteswr
itten,tryfileswritten]...
How does one decode that? The first thing you have to
realize is that
there are two "fields" that have a variable count:
- The number of entries in the filelist (e.g. /u01, /u01,
/u03, etc.)
- The number of lines in the status output (e.g. Mounting
tape x,
Positioning tape x, etc.)
If you know the format above, you can get the time of the
successful
try. Let's take a look.
==============
An explanation
==============
This time is virtually worthless, unless you want to know
when the job got
queued:
Field 9 = start time
(Time
job first got queued)
Up to Field 32, all fields are fixed. Then Field 32 tells
you how many
entries there are in the filelist fields.
Field 32 =
filelistcount (How
many files are listed in the filelist)
Then, if you add that value to 33, you'll get the field that
shows you the
number of tries.
Field 33 + filelistcount = trycount
(How
many tries there are)
If there's only one try, and you want its starttime, then
add 33,
filelistcount + 4,
and you've got the field that shows you the starttime of the
first try:
Field 33 + filelistcount + 4 =
[first]trystarted (The
starttime of the first try)
But, if there were _two_ tries, then you've got to wade past
the status
entries. First, you'll need the number of entries in the
status field.
To get that, add _9_ to 33 and the filelistcount:
Field 33 + filelistcount + 9 =
trystatuscount (The
number of status entries in the first try)
Then , to get the starttime of the SECOND try, add 33,
filelistcount, 9,
trystatuscount, and 6:
Field 33 + filelistcount + 9 + trystatuscount+6 =
[second]trystarted (The
start time of the second try)
=======================
An example
=======================
First off, I'll tell you that perl is much better at this
than awk. If you
go over a certain number of characters, awk will complain
that the line is
too long. Perl doesn't complain at all. Perl is your
friend.
The following is a real status line from a backup. First,
we want the
filelistcount:
# bpdbjobs -report -all_columns|grep '^306,' |awk -F','
'{print $32}'
1
So, there is only one entry in the filelist. (Which is
usually the case in
my configurations, since I usually select 'Allow multiple
data streams,'
and use "ALL_LOCAL_DRIVES" as the file list, which results
in a separate
job for each filesystem.) Check it out:
# bpdbjobs -report -all_columns|grep '^306,' |awk -F','
'{print $33}'
/u06
33 + 1 = 34
# bpdbjobs -report -all_columns|grep '^306,' |awk -F','
'{print $34}'
2
So, there were two tries. We'll have to do it the hard way.
First, just
for GP, we'll get the start time of the first try:
33 + 1 + 4 = 38
# bpdbjobs -report -all_columns|grep '^306,' |awk -F','
'{print $38}'
968698322
Now, let's get the start time of the second try. But first,
we'll have to
get the number of status entries.
33 + 1 + 9 = 43
# bpdbjobs -report -all_columns|grep '^306,' |awk -F','
'{print $38}'
43
So there are 43 status entries. (Yes, that's a coincidence
that they're
the same number.) So we add that to the other numbers, add
9, and we've
got the start time of the second try.
33 + 1 + 9 + 43 + 6 = 92
# bpdbjobs -report -all_columns|grep '^306,' |awk -F','
'{print $92}'
968703872
There you go!
306,0,3,0,elvis,Full,elvis,vault,0968697806,0000010002,0968707808,vault,2,,1
8497655,344,,,2302,root,0,0,0,0,other,vault,4,1,0,0,0,1,/u06,2,2302,vault,va
ult,968698322,5549,968703871,24,socket
write failed,43,09/11/2000 11:52:00 - connecting,09/11/2000
11:52:00 -
connected; connect time: 000:00:00,09/11/2000 11:52:00 -
mounting
CID304,09/11/2000 11:52:00 - mounted; mount time:
000:00:00,09/11/2000
11:52:00 - positioning to file 75,09/11/2000 11:52:00 -
positioned;
position time: 000:00:00,09/11/2000 11:52:00 - begin
writing,09/11/2000
11:52:00 - positioning to file 76,09/11/2000 11:52:00 -
positioned;
position time: 000:00:00,09/11/2000 11:59:20 - positioning
to file
77,09/11/2000 11:59:20 - positioned; position time:
000:00:00,09/11/2000
12:06:20 - positioning to file 78,09/11/2000 12:06:20 -
positioned;
position time: 000:00:00,09/11/2000 12:13:00 - positioning
to file
79,09/11/2000 12:13:00 - positioned; position time:
000:00:00,09/11/2000
12:14:30 - positioning to file 80,09/11/2000 12:14:30 -
positioned;
position time: 000:00:00,09/11/2000 12:21:30 - positioning
to file
81,09/11/2000 12:21:30 - positioned; position time:
000:00:00,09/11/2000
12:23:40 - positioning to file 82,09/11/2000 12:23:40 -
positioned;
position time: 000:00:00,09/11/2000 12:28:30 - positioning
to file
83,09/11/2000 12:28:30 - positioned; position time:
000:00:00,09/11/2000
12:30:50 - positioning to file 84,09/11/2000 12:30:50 -
positioned;
position time: 000:00:00,09/11/2000 12:31:30 - positioning
to file
85,09/11/2000 12:31:30 - positioned; position time:
000:00:00,09/11/2000
12:38:30 - positioning to file 86,09/11/2000 12:38:30 -
positioned;
position time: 000:00:00,09/11/2000 12:46:00 - positioning
to file
87,09/11/2000 12:46:00 - positioned; position time:
000:00:00,09/11/2000
12:53:10 - positioning to file 88,09/11/2000 12:53:10 -
positioned;
position time: 000:00:00,09/11/2000 12:53:40 - positioning
to file
89,09/11/2000 12:53:40 - positioned; position time:
000:00:00,09/11/2000
13:01:30 - positioning to file 90,09/11/2000 13:01:30 -
positioned;
position time: 000:00:00,09/11/2000 13:09:50 - positioning
to file
91,09/11/2000 13:09:50 - positioned; position time:
000:00:00,09/11/2000
13:19:20 - positioning to file 92,09/11/2000 13:19:20 -
positioned;
position time: 000:00:00,09/11/2000 13:23:20 - mounting
CID312,09/11/2000
13:24:30 - end writing; write time:
001:32:28,17114076,200,2302,vault,vault,968703872,3936,968707808,0,the
requested operation was successfully completed,26,09/11/2000
13:24:30 -
connecting,09/11/2000 13:24:30 - connected; connect time:
000:00:00,09/11/2000 13:24:40 - mounting CID312,09/11/2000
13:24:40 -
mounted; mount time: 000:00:00,09/11/2000 13:24:40 -
positioning to file
1,09/11/2000 13:24:50 - positioned; position time:
000:00:09,09/11/2000
13:24:50 - begin writing,09/11/2000 13:33:50 - positioning
to file
2,09/11/2000 13:33:50 - positioned; position time:
000:00:00,09/11/2000
13:40:30 - positioning to file 3,09/11/2000 13:40:30 -
positioned; position
time: 000:00:00,09/11/2000 13:47:10 - positioning to file
4,09/11/2000
13:47:10 - positioned; position time: 000:00:00,09/11/2000
13:54:00 -
positioning to file 5,09/11/2000 13:54:00 - positioned;
position time:
000:00:00,09/11/2000 14:00:30 - positioning to file
6,09/11/2000 14:00:30 -
positioned; position time: 000:00:00,09/11/2000 14:07:20 -
positioning to
file 7,09/11/2000 14:07:20 - positioned; position time:
000:00:00,09/11/2000 14:14:20 - positioning to file
8,09/11/2000 14:14:20 -
positioned; position time: 000:00:00,09/11/2000 14:21:20 -
positioning to
file 9,09/11/2000 14:21:20 - positioned; position time:
000:00:00,09/11/2000 14:27:50 - positioning to file
10,09/11/2000 14:27:50
- positioned; position time: 000:00:00,09/11/2000 14:30:00 -
end writing;
write time: 001:05:09,18497655,344
At 01:59 PM 6/22/2001 -0600, Peter Smith wrote:
>There used to be a way to decode the number you see in the
backup id. Does
>anyone remember how to do this?
>
>Peter Smith
>Convergent Data Services Inc.
>www.convergentdata.net
>720-482-9559 (work)
>720-482-0907 (fax)
>
>_______________________________________________
>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT
edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
---
W. Curtis Preston
Principal Consultant for Storage Designs, your storage
experts
Webmaster: http://www.backupcentral.com Phone: 760 631 7991
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
