> 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.


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.
> 

> 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