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