I just sat down and read the new global backup and restore procedure the 
guys are working on. They want my input on it.

On reading it, my initial reaction was "OMG, you have *got* to be 
*kidding* me! WTF?!"

I'm now attempting to write a responce to them... Really struggling not 
to be flippant here! Just how *do* you tell somebody that there ideas 
are completely stupid in a tactful way?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> Just how *do* you tell somebody that there ideas 
> are completely stupid in a tactful way?
> 

Try to understand where they are coming from.  Empathy is underrated.

Post a reply to this message

Tom Galvin wrote:
> Invisible wrote:
>> Just how *do* you tell somebody that there ideas are completely stupid 
>> in a tactful way?
>>
> 
> Try to understand where they are coming from.  Empathy is underrated.


Yeah, what he said.



Think about it for a moment - how would you like people to respond to 
something that you worked hard to put together and asked for feedback on.

If you reject their plan and submit a new one, your input will likely 
get tossed.

If you make some good suggestions with supporting info, then some may 
actually get incorporated.  You may even be asked for more information.

The trick is in getting someone to see their own error and make their 
own change on their own - something I am not good at.  For some reason 
people take things better that way.




Tom

Post a reply to this message

Tom Austin wrote:
> Tom Galvin wrote:
>> Invisible wrote:
>>> Just how *do* you tell somebody that there ideas are completely 
>>> stupid in a tactful way?
>>>
>>
>> Try to understand where they are coming from.  Empathy is underrated.
> 
> 
> Yeah, what he said.

Exactly.

Think of it in terms of "how would I teach/explain a complicated thing 
to a naive user, or a child" kind of thing. Try to figure out why they 
think it'll do what they want, then find the flaws in it. In other 
words, try to work backwards from what they wrote to what they expect it 
to accomplish, then explain the ways in which it could fail.

Doing this can be extremely difficult if you're very well versed in the 
field.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Wed, 30 Jul 2008 10:32:09 +0100, Invisible wrote:

> I just sat down and read the new global backup and restore procedure the
> guys are working on. They want my input on it.
> 
> On reading it, my initial reaction was "OMG, you have *got* to be
> *kidding* me! WTF?!"
> 
> I'm now attempting to write a responce to them... Really struggling not
> to be flippant here! Just how *do* you tell somebody that there ideas
> are completely stupid in a tactful way?

Don't tell them their ideas are bad; present better ideas instead.  :-)

Jim

Post a reply to this message

On Wed, 30 Jul 2008 08:47:36 -0400, Tom Austin wrote:

> Tom Galvin wrote:
>> Invisible wrote:
>>> Just how *do* you tell somebody that there ideas are completely stupid
>>> in a tactful way?
>>>
>>>
>> Try to understand where they are coming from.  Empathy is underrated.
> 
> 
> Yeah, what he said.
> 
> 
> 
> Think about it for a moment - how would you like people to respond to
> something that you worked hard to put together and asked for feedback
> on.
> 
> If you reject their plan and submit a new one, your input will likely
> get tossed.
> 
> If you make some good suggestions with supporting info, then some may
> actually get incorporated.  You may even be asked for more information.
> 
> The trick is in getting someone to see their own error and make their
> own change on their own - something I am not good at.  For some reason
> people take things better that way.

And this is more or less what I mean by "present better ideas" - Tom, 
Tom, and Darren all three hit on a key part of this, which is to make 
sure that you're not tearing down their ideas, but instead getting them 
to see something that'll work better.  It always works out better if 
others can see that they've made a mistake rather than being told "dude, 
you're just wrong on this".  Sometimes the "you're just wrong" approach 
is called for, but those times are not as frequent as most people think.

"Your baby's ugly" doesn't win friends and influence people. :-)

Jim

Post a reply to this message

Invisible wrote:

> I'm now attempting to write a responce to them... Really struggling not 
> to be flippant here! Just how *do* you tell somebody that there ideas 
> are completely stupid in a tactful way?

I have just sent a large... 10-point email... explaining... step by 
step... in meticulous detail... precisely why I think that THIS PLAN IS 
FRIGGIN RIDICULOUS!! >_<

Sorry, I ran out of calmness at the end there. Fortunately, you can edit 
emails UNTIL you send them. ;-)




For anyone who's interested...

1. They want to keep backup tapes (even differentials) forever. (No 
regulations require this.)

2. They want to allow the vagaries of the Gregorian calendar and its 
lack of synchronisation with the 7-day week affect when our backups do 
and don't happen.

3. They want to keep the weeks' tapes in the server room until the end 
of the week.

4. They want to verify that tape restoration works by restoring a 
standardised, unchanging 0.09 KB file and performing a visual inspection 
to check that it "looks the same". (In fairness, if the backup software 
says it's restored, you can be 99% sure it's fine. Usually if there's a 
problem the software will complain that it "can't" restore the file, 
rather than restore gibberish. But even so...)

5. The order in which tapes are run is not clearly described. In fact, 
the relevant section is utterly incomprehensible. Surely *they* know 
what they meant - but *I* haven't got a clue!

6. Similarly, there's a new form to fill out - but I don't understand 
why, what does on it, or when it's meant to be done.

7. The procedure talks about "software backups". As most of you won't 
know, the regulations make a distinction between "backups" and "archive 
copies", and this document is confablating the two. The result is a most 
inappropriate procedure, which is outside the scope of the document anyway.

8. Did I mention yet that THIS PLAN IS CRAZY?!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:

> I have just sent a large... 10-point email... explaining... step by 
> step... in meticulous detail... precisely why I think that THIS PLAN IS 
> FRIGGIN RIDICULOUS!! >_<
> 
> Sorry, I ran out of calmness at the end there. Fortunately, you can edit 
> emails UNTIL you send them. ;-)

...and the guy just laughed and told me to put it into the comments 
inside the Word document.

Great. Now I have to work out how Word's comment system works... :-S

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message
news:4891b52d$1@news.povray.org...
> Invisible wrote:
>
> > I have just sent a large... 10-point email... explaining... step by
> > step... in meticulous detail... precisely why I think that THIS PLAN IS
> > FRIGGIN RIDICULOUS!! >_<
> >
> > Sorry, I ran out of calmness at the end there. Fortunately, you can edit
> > emails UNTIL you send them. ;-)
>
> ...and the guy just laughed and told me to put it into the comments
> inside the Word document.
>
> Great. Now I have to work out how Word's comment system works... :-S

In Word 2000, Tools -> Track Changes

Post a reply to this message

>> Great. Now I have to work out how Word's comment system works... :-S
> 
> In Word 2000, Tools -> Track Changes

Track Changes is already turned on. What I need to do is somehow 
comprehend the rat's nest of comments and alterations that are already 
there, and figure out how to add my own comments. (And, frankly, given 
that most of my comments aren't like "this sentence is should be 
rephrased" but more "this entire document is fundamentally wrong", it's 
not obvious where to put such comments...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

> Track Changes is already turned on. What I need to do is somehow 
> comprehend the rat's nest of comments and alterations that are already 
> there, and figure out how to add my own comments. (And, frankly, given 
> that most of my comments aren't like "this sentence is should be 
> rephrased" but more "this entire document is fundamentally wrong", it's 
> not obvious where to put such comments...)

Draw a text box over the top and put it in Arial size 64 bold red.  That 
should do it.

Post a reply to this message

scott wrote:
>> Track Changes is already turned on. What I need to do is somehow 
>> comprehend the rat's nest of comments and alterations that are already 
>> there, and figure out how to add my own comments. (And, frankly, given 
>> that most of my comments aren't like "this sentence is should be 
>> rephrased" but more "this entire document is fundamentally wrong", 
>> it's not obvious where to put such comments...)
> 
> Draw a text box over the top and put it in Arial size 64 bold red.  That 
> should do it.

Sir, I like your thinking. ;-)

Not sure whether this could be considered in any way "tactful" though...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> 
> For anyone who's interested...
> 
> 1. They want to keep backup tapes (even differentials) forever. (No 
> regulations require this.)
> 

Ask why they want to do this.  You were not in the meeting where they 
decided to do this.  They should be happy to tell you.

> 2. They want to allow the vagaries of the Gregorian calendar and its 
> lack of synchronisation with the 7-day week affect when our backups do 
> and don't happen.

Ask why?

> 
> 3. They want to keep the weeks' tapes in the server room until the end 
> of the week.
> 

Provide your observations about the potential risks to this choice, and 
the benefits of alternatives.

> 4. They want to verify that tape restoration works by restoring a 
> standardised, unchanging 0.09 KB file and performing a visual inspection 
> to check that it "looks the same". (In fairness, if the backup software 
> says it's restored, you can be 99% sure it's fine. Usually if there's a 
> problem the software will complain that it "can't" restore the file, 
> rather than restore gibberish. But even so...)
> 

Be nice, and give constructive feedback.


> 5. The order in which tapes are run is not clearly described. In fact, 
> the relevant section is utterly incomprehensible. Surely *they* know 
> what they meant - but *I* haven't got a clue!
> 

Ask for clarification.


> 6. Similarly, there's a new form to fill out - but I don't understand 
> why, what does on it, or when it's meant to be done.
> 

Ask and you shall receive.

> 7. The procedure talks about "software backups". As most of you won't 
> know, the regulations make a distinction between "backups" and "archive 
> copies", and this document is confablating the two. The result is a most 
> inappropriate procedure, which is outside the scope of the document anyway.
> 

Point out the confusion and ask for clarification.

> 8. Did I mention yet that THIS PLAN IS CRAZY?!
> 

Yes but you fail to explain why it is crazy.

Post a reply to this message

Tom Galvin wrote:
> Invisible wrote:
>>
>> For anyone who's interested...
>>
>> 1. They want to keep backup tapes (even differentials) forever. (No 
>> regulations require this.)
>>
> 
> Ask why they want to do this.  You were not in the meeting where they 
> decided to do this.  They should be happy to tell you.

Include an estimate for the cost of tapes for one year of backups, as 
well. Don't forget the cost of storing them securely off-site.

>> 2. They want to allow the vagaries of the Gregorian calendar and its 
>> lack of synchronisation with the 7-day week affect when our backups do 
>> and don't happen.
> 
> Ask why?

That honestly doesn't seem too problematic to me, unless you want to 
utterly automate the backups. Given you have to be there to change 
tapes, have a script that does the first-of-month backup and another 
that does the friday-backup, for example.

I can even understand why they might want such a thing, if it makes it 
easier to find files from a particular day in a long collection of backups.

>> 3. They want to keep the weeks' tapes in the server room until the end 
>> of the week.
>>
> 
> Provide your observations about the potential risks to this choice, and 
> the benefits of alternatives.

Also point out the cost of buying a secured fireproof media safe big 
enough to hold a week's worth of backup tapes. (Hint: they aren't 
cheap.) Note that a fireproof safe that will keep tapes safe isn't the 
same as a fireproof tape that will keep paper safe.

>> 4. They want to verify that tape restoration works by restoring a 
>> standardised, unchanging 0.09 KB file and performing a visual 
>> inspection to check that it "looks the same". (In fairness, if the 
>> backup software says it's restored, you can be 99% sure it's fine. 
>> Usually if there's a problem the software will complain that it 
>> "can't" restore the file, rather than restore gibberish. But even so...)
>>
> 
> Be nice, and give constructive feedback.

Again, shouldn't be hard. Ask if you can back up the file then use an 
automated comparison rather than a visual comparison to make sure it 
worked.

>> 5. The order in which tapes are run is not clearly described. In fact, 
>> the relevant section is utterly incomprehensible. Surely *they* know 
>> what they meant - but *I* haven't got a clue!
>>
> 
> Ask for clarification.

Exactly, yes. Then, create a chart for a couple months of backups, and 
include it and say "please check that I have correctly paraphrased your 
instructions."  Then follow the chart if they say it's OK.

>> 6. Similarly, there's a new form to fill out - but I don't understand 
>> why, what does on it, or when it's meant to be done.
> 
> Ask and you shall receive.

Yeah, these don't seem like WTF problems as much as "we didn't write 
down everything we talked about".

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

>>> 1. They want to keep backup tapes (even differentials) forever. (No 
>>> regulations require this.)
>>>
>>
>> Ask why they want to do this.  You were not in the meeting where they 
>> decided to do this.  They should be happy to tell you.
> 
> Include an estimate for the cost of tapes for one year of backups, as 
> well. Don't forget the cost of storing them securely off-site.

Well, a box of 5 LTO tapes is £130 from Dell. So that's already a few 
hundred pounds per year.

Interestingly, I worked out that based on the dimensions of an LTO tape 
[not sure if this is with or without case] you can store enough takes in 
1 m^2 for 360 years of backups. :^}

Neither of these arguments look particularly compelling. It's more the 
fact that there is ABSOLUTELY NO REASON TO DO THIS that annoys me...

>>> 2. They want to allow the vagaries of the Gregorian calendar and its 
>>> lack of synchronisation with the 7-day week affect when our backups 
>>> do and don't happen.
>>
>> Ask why?
> 
> That honestly doesn't seem too problematic to me.

I just dislike having the backup frequency vary at random, that's all. 
The idea of keeping hold of these backups is so that we can go back. I'd 
really hate to say "gee, I can't restore that file because that 
particular month was a day longer than the others".

>>> 4. They want to verify that tape restoration works by restoring a 
>>> standardised, unchanging 0.09 KB file and performing a visual 
>>> inspection to check that it "looks the same". (In fairness, if the 
>>> backup software says it's restored, you can be 99% sure it's fine. 
>>> Usually if there's a problem the software will complain that it 
>>> "can't" restore the file, rather than restore gibberish. But even so...)
>>
>> Be nice, and give constructive feedback.
> 
> Again, shouldn't be hard. Ask if you can back up the file then use an 
> automated comparison rather than a visual comparison to make sure it 
> worked.

I suggested MD5 hashes or something would be a good idea. I even 
suggested a procedure for using 'em...

>>> 5. The order in which tapes are run is not clearly described. In 
>>> fact, the relevant section is utterly incomprehensible. Surely *they* 
>>> know what they meant - but *I* haven't got a clue!
>>>
>>
>> Ask for clarification.
> 
> Exactly, yes. Then, create a chart for a couple months of backups, and 
> include it and say "please check that I have correctly paraphrased your 
> instructions."  Then follow the chart if they say it's OK.

That's the amusing part - there *is* a chart in the document! It just 
doesn't make any *sense*. :-/

> Yeah, these don't seem like WTF problems as much as "we didn't write 
> down everything we talked about".

Highly likely. But hey, that's why we review these things...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Thu, 31 Jul 2008 10:13:25 -0400, Tom Galvin wrote:

> Invisible wrote:
>> 
>> For anyone who's interested...
>> 
>> 1. They want to keep backup tapes (even differentials) forever. (No
>> regulations require this.)
>> 
>> 
> Ask why they want to do this.  You were not in the meeting where they
> decided to do this.  They should be happy to tell you.

It sounds to me like they lack an understanding of "archival" vs. 
"backup".

>> 2. They want to allow the vagaries of the Gregorian calendar and its
>> lack of synchronisation with the 7-day week affect when our backups do
>> and don't happen.
> 
> Ask why?

I'm trying to remember if this is how the old Palindrome system worked - 
it used a Grandfather-Father-Son backup scheme that is common in the 
mainframe world, and while Palindrome used our calendar for its schedule, 
it may be a variation of this that doesn't is what they're using.

>> 3. They want to keep the weeks' tapes in the server room until the end
>> of the week.
>> 
>> 
> Provide your observations about the potential risks to this choice, and
> the benefits of alternatives.

ISTR this is typically done this so you could do restores of individual 
files; if you needed to restore the entire system, you'd have to pull the 
last full backup from offsite storage.  It depends on the value of the 
data if its lost.

>> 4. They want to verify that tape restoration works by restoring a
>> standardised, unchanging 0.09 KB file and performing a visual
>> inspection to check that it "looks the same". (In fairness, if the
>> backup software says it's restored, you can be 99% sure it's fine.
>> Usually if there's a problem the software will complain that it "can't"
>> restore the file, rather than restore gibberish. But even so...)
>> 
> Be nice, and give constructive feedback.

Agreed.  That said, doing a restore is much better than depending on the 
tape drive's report during the backup of problems.  I've been burned by 
that - it said data was being written, but it was unreadable due to tape 
errors (that was old DAT technology years ago, so the newer stuff is 
probably better, but I'd still trust at least a read with error checking 
of the tape over any reporting that comes back during the backup).

>> 5. The order in which tapes are run is not clearly described. In fact,
>> the relevant section is utterly incomprehensible. Surely *they* know
>> what they meant - but *I* haven't got a clue!
>> 
>> 
> Ask for clarification.

Just Invis' description sounds like GFS style backups.  It's a style that 
some people find difficult to describe.

Jim

Post a reply to this message

Invisible wrote:
>>>> 1. They want to keep backup tapes (even differentials) forever. (No 
>>>> regulations require this.)
>>>>
>>>
>>> Ask why they want to do this.  You were not in the meeting where they 
>>> decided to do this.  They should be happy to tell you.
>>
>> Include an estimate for the cost of tapes for one year of backups, as 
>> well. Don't forget the cost of storing them securely off-site.
> 
> Well, a box of 5 LTO tapes is £130 from Dell. So that's already a few 
> hundred pounds per year.

You're going to store an entire set of backups on 5 or 10 tapes?  Aren't 
you backing things up every week, or every day?

> Interestingly, I worked out that based on the dimensions of an LTO tape 
> [not sure if this is with or without case] you can store enough takes in 
> 1 m^2 for 360 years of backups. :^}

Only if you fill the tapes. And a cubic meter of media safe storage is 
pretty expensive.

> Neither of these arguments look particularly compelling. It's more the 
> fact that there is ABSOLUTELY NO REASON TO DO THIS that annoys me...

No, but you should (a) ask why they want to do this (as in, "please 
describe for me when you might want to access backups this old, that I 
might work out a way of labeling the tapes to make it easy to find what 
you're looking for") and (b) point out that they do indeed need to 
budget a thousand pounds to buy tapes and storage.

> I just dislike having the backup frequency vary at random, that's all. 
> The idea of keeping hold of these backups is so that we can go back. I'd 
> really hate to say "gee, I can't restore that file because that 
> particular month was a day longer than the others".

See above: "when might you want to go back to these old tapes?" when 
they answer "how should we handle the situation when the month is a day 
longer, and we didn't make a back up that day?"

If you phrase everything as a reasonable question, it's more difficult 
to get upset at the person asking. (Not impossible, mind; see the "shoot 
the messenger" syndrome.)

>>> Be nice, and give constructive feedback.
>>
>> Again, shouldn't be hard. Ask if you can back up the file then use an 
>> automated comparison rather than a visual comparison to make sure it 
>> worked.
> 
> I suggested MD5 hashes or something would be a good idea. I even 
> suggested a procedure for using 'em...

What's wrong with "comp"?  Or just a little program to read two files 
and compare the contents, if that's what they're really worried about?

> That's the amusing part - there *is* a chart in the document! It just 
> doesn't make any *sense*. :-/

Well, ask them to express the chart as a calendar, since you don't 
understand what it means. Or otherwise ask them what you're confused 
about. If there's contradictory information in the chart, come up with 
an example that matches both contradictory elements and ask what the 
answer is, after pointing out that one element in the chart says yes and 
the other says no.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Jim Henderson wrote:
> I'm trying to remember if this is how the old Palindrome system worked - 
> it used a Grandfather-Father-Son backup scheme that is common in the 
> mainframe world, and while Palindrome used our calendar for its schedule, 
> it may be a variation of this that doesn't is what they're using.

http://en.wikipedia.org/wiki/Backup_rotation_scheme

> Just Invis' description sounds like GFS style backups.  It's a style that 
> some people find difficult to describe.

I didn't know GFS did backups, other than to other machines. Unless 
you're talking about a different GFS. :)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Thu, 31 Jul 2008 09:50:14 -0700, Darren New wrote:

> Jim Henderson wrote:
>> I'm trying to remember if this is how the old Palindrome system worked
>> - it used a Grandfather-Father-Son backup scheme that is common in the
>> mainframe world, and while Palindrome used our calendar for its
>> schedule, it may be a variation of this that doesn't is what they're
>> using.
> 
> http://en.wikipedia.org/wiki/Backup_rotation_scheme

That's the one.

>> Just Invis' description sounds like GFS style backups.  It's a style
>> that some people find difficult to describe.
> 
> I didn't know GFS did backups, other than to other machines. Unless
> you're talking about a different GFS. :)

Yeah, Grandfather-Father-Son. ;-)

Jim

Post a reply to this message

Jim Henderson wrote:
>> I didn't know GFS did backups, other than to other machines. Unless
>> you're talking about a different GFS. :)
> 
> Yeah, Grandfather-Father-Son. ;-)

Oh. Duh. Right.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Thu, 31 Jul 2008 10:41:19 -0700, Darren New wrote:

> Jim Henderson wrote:
>>> I didn't know GFS did backups, other than to other machines. Unless
>>> you're talking about a different GFS. :)
>> 
>> Yeah, Grandfather-Father-Son. ;-)
> 
> Oh. Duh. Right.

We all have our moments.  ;-)

Jim

Post a reply to this message

Jim Henderson wrote:

> It sounds to me like they lack an understanding of "archival" vs. 
> "backup".

Precisely.

(There's also talk about how to "back up" our software so we don't lose it.)

Note also that there is a regulatory distinction between the two terms, 
and the government holds us to those regulations.

>>> 3. They want to keep the weeks' tapes in the server room until the end
>>> of the week.
>>>
>> Provide your observations about the potential risks to this choice, and
>> the benefits of alternatives.
> 
> ISTR this is typically done this so you could do restores of individual 
> files; if you needed to restore the entire system, you'd have to pull the 
> last full backup from offsite storage.  It depends on the value of the 
> data if its lost.

Actually it seems to be so they don't have to bother actually attending 
to the machine except once a week. To my mind, leaving all the tapes 
right next to the server rather negates the entire purpose of daily 
backups. If we're going to play that game, why not just only back up 
once a week?

[Yeah, I realise it's not *quite* the same, but you see what I'm saying.]

> Agreed.  That said, doing a restore is much better than depending on the 
> tape drive's report during the backup of problems.  I've been burned by 
> that - it said data was being written, but it was unreadable due to tape 
> errors.

Standard procedure is to record the data, rewind the tape, read back all 
the data and check it actually matches what's on disk, not just that the 
checksums on the tape are OK. Still, it seems reasonable to go a step 
further and actually test the thing "for real" by actually performing a 
backup. I'm not sure it needs to happen every 3 months though...

> Just Invis' description sounds like GFS style backups.  It's a style that 
> some people find difficult to describe.

Yeah, it's GFS. However, the chart they supplied seems to indicate that 
there is only one grandfather tape, only one father tape, and only one 
son tape. In other words, if you want to restore from 2 days ago, the 
tape has already been overwritten. Like, WTF? So clearly that can't be 
what they mean. Hey, it's not like anything is *labelled* or anything 
like that...

As I asserted, it probably made perfect sense to the guy who scribbled 
it down.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> Well, a box of 5 LTO tapes is £130 from Dell. So that's already a few 
>> hundred pounds per year.
> 
> You're going to store an entire set of backups on 5 or 10 tapes?  Aren't 
> you backing things up every week, or every day?

They want to keep every monthly backup forever. The other tapes get 
rotated for a year, and then the whole lot get "archived". So we have 
full backups from each month, and then a load of differential backups 
from the last few days of the year. Like, WTF?

>> Interestingly, I worked out that based on the dimensions of an LTO 
>> tape [not sure if this is with or without case] you can store enough 
>> takes in 1 m^2 for 360 years of backups. :^}
> 
> Only if you fill the tapes. And a cubic meter of media safe storage is 
> pretty expensive.

Yeah, but I was thinking that after a year or two we'd have a whole 
*room* full of stuff. Clearly that isn't really the case.

> If you phrase everything as a reasonable question, it's more difficult 
> to get upset at the person asking. (Not impossible, mind; see the "shoot 
> the messenger" syndrome.)

I don't know about you, but I tend to find that if I ask anything or add 
any comments, these are all silently ignored. Because ignoring problems 
makes them go away, doesn't it?

>> I suggested MD5 hashes or something would be a good idea. I even 
>> suggested a procedure for using 'em...
> 
> What's wrong with "comp"?

Does that exist on Windoze?

> Or just a little program to read two files 
> and compare the contents, if that's what they're really worried about?

Yeah, we could do that. MD5 has the nice property that it can be written 
down on a sheet of paper, and easily checked again later. But for this 
particular scenario, a basic file compare would be fine. (We would 
probably have to formally test the correctness of the compare program 
though!)

>> That's the amusing part - there *is* a chart in the document! It just 
>> doesn't make any *sense*. :-/
> 
> Well, ask them to express the chart as a calendar, since you don't 
> understand what it means. Or otherwise ask them what you're confused 
> about. If there's contradictory information in the chart, come up with 
> an example that matches both contradictory elements and ask what the 
> answer is, after pointing out that one element in the chart says yes and 
> the other says no.

The chart *is* a calendar - but it shows only 1 son tape, 1 father tape, 
and 1 grandfather tape, which makes no sense at all. But then, none of 
the parts are labelled, so you have to take guesses at what it's saying...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Thu, 31 Jul 2008 21:04:06 +0100, Orchid XP v8 wrote:

> Jim Henderson wrote:
> 
>> It sounds to me like they lack an understanding of "archival" vs.
>> "backup".
> 
> Precisely.
> 
> (There's also talk about how to "back up" our software so we don't lose
> it.)
> 
> Note also that there is a regulatory distinction between the two terms,
> and the government holds us to those regulations.

Then in your comments, you need to cite the regulations in particular, 
along with the "definitions" section (if it exists; most regulations do 
have some section somewhere that defines terms).

>> ISTR this is typically done this so you could do restores of individual
>> files; if you needed to restore the entire system, you'd have to pull
>> the last full backup from offsite storage.  It depends on the value of
>> the data if its lost.
> 
> Actually it seems to be so they don't have to bother actually attending
> to the machine except once a week. To my mind, leaving all the tapes
> right next to the server rather negates the entire purpose of daily
> backups. If we're going to play that game, why not just only back up
> once a week?

Well, actually, it doesn't negate the purpose of daily backups.  You're 
assuming (perhaps) that the backups are useful only in case something 
catastrophic happens to he building - like it burns to the ground (in 
which case, your argument is valid).  But "dumb user Joe Smith" deletes a 
file he needs or it gets corrupted - having the backup right there is the 
fastest path to recovery short of an undelete utility (which can have 
their own problems).

> [Yeah, I realise it's not *quite* the same, but you see what I'm
> saying.]

Yeah, but that scenario is a single use case out of a few.  When 
structuring your arguments, you don't want to pick a specialized low-risk/
high-cost scenario and use that as the basis for your argument.

>> Agreed.  That said, doing a restore is much better than depending on
>> the tape drive's report during the backup of problems.  I've been
>> burned by that - it said data was being written, but it was unreadable
>> due to tape errors.
> 
> Standard procedure is to record the data, rewind the tape, read back all
> the data and check it actually matches what's on disk, not just that the
> checksums on the tape are OK. Still, it seems reasonable to go a step
> further and actually test the thing "for real" by actually performing a
> backup. I'm not sure it needs to happen every 3 months though...

That is a reasonable procedure IME.  A full restore on a regular basis 
isn't a bad idea, just to rule out the tape drive lying on its read 
test.  Incidentally, that's what I believe happened to me just before a 
catastrophic disk failure on a finance server that was followed by the 
realisation that we could not restore ANY of the data from the tapes 
because the tapes were part of a bad batch - and the software we used was 
too stupid to skip over read errors on a restore, but instead would abort 
the restore completely.

Even still, we did manage to recover 3/4 of the data with some help from 
the software vendor.

>> Just Invis' description sounds like GFS style backups.  It's a style
>> that some people find difficult to describe.
> 
> Yeah, it's GFS. However, the chart they supplied seems to indicate that
> there is only one grandfather tape, only one father tape, and only one
> son tape. In other words, if you want to restore from 2 days ago, the
> tape has already been overwritten. Like, WTF? So clearly that can't be
> what they mean. Hey, it's not like anything is *labelled* or anything
> like that...

Well, it depends partly whether incrementals are used for the F & S or 
differentials are used.  If a differential tape is done (ie, since the 
last F or G, depending on whether we're talking about the S or F tape), 
then it picks up all changes since the last "full" backup (ie, G or F 
tape).  I would probably prefer to use at least 2 tapes in the rotation, 
though when using differentials - if the write to the tape bombs the 
second time around, then you've also overwritten your earlier 
differential and you lose that much more data.  With two, you at least 
can go back to the previous day.

> As I asserted, it probably made perfect sense to the guy who scribbled
> it down.

Very likely.  One thing I do in situations like that is try to restate 
what has been stated and ask if my understanding is correct.  That 
usually helps the writer - especially if what you repeat back isn't what 
was meant.

Jim

Post a reply to this message

Orchid XP v8 wrote:
> They want to keep every monthly backup forever. The other tapes get 
> rotated for a year, and then the whole lot get "archived". So we have 
> full backups from each month, and then a load of differential backups 
> from the last few days of the year. Like, WTF?

So ask them when they'd expect to use those tapes. Maybe there's some 
regulatory or accounting mechanism that requires them to be saved. Point 
out where files that were changed in October won't be saved on either 
the Jan or Dec tapes. Ask them under what situations they'd expect to 
use the differential tapes.

>>> I suggested MD5 hashes or something would be a good idea. I even 
>>> suggested a procedure for using 'em...
>>
>> What's wrong with "comp"?
> 
> Does that exist on Windoze?

It exists in DOS 1.0 and everything after it.

> particular scenario, a basic file compare would be fine. (We would 
> probably have to formally test the correctness of the compare program 
> though!)

You could probably do that if you wrote it in Haskell. ;-)

> The chart *is* a calendar - but it shows only 1 son tape, 1 father tape, 
> and 1 grandfather tape, which makes no sense at all. But then, none of 
> the parts are labelled, so you have to take guesses at what it's saying...

Ask to clarify. Or guess, and ask them to confirm.

Not that it helps. I once spent a couple weeks and did 30 pages of UI 
design, showed it to the person in charge, had her initial each page as 
being right, and when the program was all done, she comes back with "OK, 
now let's work out what the screens should look like."  Hey, b___h, if I 
hadn't hardcoded the screens, I wouldn't be asking you to read them, now 
would I?  (And yes, everyone thought she was a b___h, but she was 
sleeping with the CEO, so...)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Orchid XP v8 wrote:
>> What's wrong with "comp"?
> 
> Does that exist on Windoze?

Yes it does. In Unix it's "cmp".

Post a reply to this message

>> particular scenario, a basic file compare would be fine. (We would 
>> probably have to formally test the correctness of the compare program 
>> though!)
> 
> You could probably do that if you wrote it in Haskell. ;-)

I *have*, in fact, written such a program in Haskell. We're currently in 
the process of formally testing it. For something completely different, 
as it happens...

(And yes, it had a bug. I forgot to open the files in binary mode, so it 
was doing line end conversions. It also stopped processing the file when 
it reached a certain octet sequence. I wonder what other bugs we'll find?)

> Ask to clarify. Or guess, and ask them to confirm.
> 
> Not that it helps. I once spent a couple weeks and did 30 pages of UI 
> design, showed it to the person in charge, had her initial each page as 
> being right, and when the program was all done, she comes back with "OK, 
> now let's work out what the screens should look like."  Hey, b___h, if I 
> hadn't hardcoded the screens, I wouldn't be asking you to read them, now 
> would I?  (And yes, everyone thought she was a b___h, but she was 
> sleeping with the CEO, so...)

Damn. I'm not sleeping with anybody. :-(

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>>> What's wrong with "comp"?
>> Does that exist on Windoze?
> 
> Yes it does. In Unix it's "cmp".

LOL! That great Unix tradition of eliding vowels at all costs...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
>>>> What's wrong with "comp"?
>>> Does that exist on Windoze?
>>
>> Yes it does. In Unix it's "cmp".
> 
> LOL! That great Unix tradition of eliding vowels at all costs...

along with the great Windows tradition of (a) picking different command 
flags for commands ported from UNIX, and (b) trying to make everything 
fit in 8.3 a decade after they got rid of that restriction in all their 
file systems.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

>> LOL! That great Unix tradition of eliding vowels at all costs...
> 
> along with the great Windows tradition of (a) picking different command 
> flags for commands ported from UNIX

I just love the way that you have to write a short Prolog program to 
discover the behaviour of most Unix commands for each given combination 
of switches.

(E.g., "-s" implies "-v" and "-c". "-k" disabled "-s". "-Q" reverses the 
sense of "-s". If "-L" is present then "-s" now controls something 
completely different. And if it's a Tuesday today then the "-R" switch 
is no-op...)

> (b) trying to make everything 
> fit in 8.3 a decade after they got rid of that restriction in all their 
> file systems.

Yeah, WTF is *that* about??

And *why* are there still programs who's installers and splash screens 
show up in dithered 256-colour or even 16-colour graphics when the 
entire civilized world has had 24-bit colour for a decade now?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:

> 
> And *why* are there still programs who's installers and splash screens 
> show up in dithered 256-colour or even 16-colour graphics when the 
> entire civilized world has had 24-bit colour for a decade now?
> 

It's an in-joke among the people who write installers. They laugh 
everytime someone says "Installers need more colors"

;)

Seriously, they're probably using an old version of installshield, or 
its in some ancient style guide somewhere ...

Post a reply to this message

*sigh*

The document has been extensively revised, and all the comments have 
vanished from it. Trouble is, it still contains the same mistakes. In 
fact, it even adds a few new ones! (E.g., on a bank holiday, don't just 
skip the tape that would have run, make the whole of the rest of the 
sequence slide backwards by one day instead.)

I give up...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Fri, 15 Aug 2008 10:22:30 +0100, Invisible wrote:

> *sigh*
> 
> The document has been extensively revised, and all the comments have
> vanished from it. Trouble is, it still contains the same mistakes. In
> fact, it even adds a few new ones! (E.g., on a bank holiday, don't just
> skip the tape that would have run, make the whole of the rest of the
> sequence slide backwards by one day instead.)
> 
> I give up...

Anything that would be considered illegal?

Jim

Post a reply to this message