Veritas-bu

[Veritas-bu] Decode number in index name

2001-06-23 01:04:09
Subject: [Veritas-bu] Decode number in index name
From: curtis AT backupcentral DOT com (W. Curtis Preston)
Date: Fri, 22 Jun 2001 22:04:09 -0700
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,ended,stunit,try,operation,kbytes,files,pathlastwritten,percent,jobpid,owner,subtype,classtype,schedule_type,priority,group,masterserver,retentionunits,retentionperiod,compression,kbyteslastwritten,fileslastwritten,filelistcount,[files]...,trycount,[trypid,trystunit,tryserver,trystarted,tryelapsed,tryended,trystatus,trystatusdescription,trystatuscount,[trystatuslines]...,trybyteswritten,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,,18497655,344,,,2302,root,0,0,0,0,other,vault,4,1,0,0,0,1,/u06,2,2302,vault,vault,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


<Prev in Thread] Current Thread [Next in Thread>