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