Jihad needs scientists
in [Design]
|
From: jmfbahciv on 3 Mar 2007 08:22 In article <eiogu2pciolp604iscrss63q7ni22aof4e(a)4ax.com>, MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >On Fri, 02 Mar 07 13:22:04 GMT, jmfbahciv(a)aol.com Gave us: > >>The case that I brought up was database; with databases, the data >>is always a moving target that can never be snap-shot with accuracy. > > > You're an idiot. That would only be true for a LIVE database. That's what I'm talking about. > If >you are doing file maintenance, the database would be a static file, There are plenty of data bases in today's online world that can never be taken off-line. Those are the ones that I've been talking about when I wrote that a snapshot is a viaable way to backup up these data bases. >and that server would be offline. I can't be offline. Access has to be 7x24x360xdecades. > > ANY file can be snapshot accurately. No, it cannot. > A database table that is >fragmented over a volume gets written in backup as a single block of >data, and nothing is lost. Some lost space is gained in fact. >Database engines allow table optimization which essentially defrags a >single file. Now think about airline scheduling systems. These are the ones that have used computers the longest. /BAH
From: Ken Smith on 3 Mar 2007 11:07 In article <esbpbe$8qk_003(a)s977.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <es9djf$q95$3(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>In article <es928h$8ss_001(a)s1006.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: >>>In article <es829g$2hl$2(a)blue.rahul.net>, >>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>[...] >>>>No, this is all silly. The backup I have been refering to is not cover in >>>>the cases in your list. What I suggested was a complete image of the >>>>drive. >>> >>>That has the problem of also preserving the bad spots of the disk. >>>I'm assuming that you do want an image of the disk and not drive. >> >>Preseving the bad spots is a feature not a problem. It is a record of >>exactly how things were warts and all that you want to keep. > >And when you restore the image, you also restore the errors. Now, >what if it is those errors which are creating the mess that >is causing you to have to rebuild your system? This is the >point I've been trying to make but you don't seem to be able >to read. You keep saying that like its not something I already knew. The backup is supposed to be an image of the system as it was. If the system was broken then that is *exactly* what the backup should be storing. You can't seem to get it through you head that the subject of making a back up and doing a repair are two different topics. >>>You are in error. Last access is an important datum. >> >>Please explain exactly how you thing the last access is important. > >I already have. You have a static file which is used all the time, >but never written. "Used all the time" means that it is accessed >often. If you only save files with the date-time stamps of >"last modified", you never get this one on any tapes other than >a full save. Ok, I have a file which is written onto a full save. I have this and many previous full saves. All of these full saves have the file on it unchanged. I also have some incremental backups which don't have that file. This is all exactly as it should be. There is no problem at all. The unchanged file should not go onto the incremental because this would just make the incremental into a "partial save". It would be needlessly large. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 3 Mar 2007 11:10 In article <esbpio$8qk_004(a)s977.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <es9djf$q95$3(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: [....] >>>You are in error. Last access is an important datum. >> >>Please explain exactly how you thing the last access is important. > >[This is the piece I inadventently deleted] > >> What >>do you do with this information? > >I, the BACKUP programmer, will save all files during an incremental >that has an access date after the date-time argument of the /SINCE >switch. This makes it no longer an "incremental". You are in fact doing a partial save on the system. The mere fact that you do something that is not an incremental and call that an incremental, doesn't make you right about any of the things you've posted on the subject. A far better way to do a backup is still to make an image of the drive. > >> In this context, the only use of that >>information will be a mistake. > >Are you interested enough to read some code which implements >this stuff correctly? Yes, do you know of any? -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 3 Mar 2007 11:23 In article <esbseb$8qk_001(a)s977.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <es9eh9$q95$5(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>In article <es95ji$8qk_001(a)s1006.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: >>>In article <es6rgr$kgg$6(a)blue.rahul.net>, >>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>In article <es6h92$8qk_001(a)s985.apx1.sbo.ma.dialup.rcn.com>, >>>> <jmfbahciv(a)aol.com> wrote: ><snip> > >>>Honey, you are not paranoid enough. >> >>I have suggested the reasonable way to deal with the problems of doing a >>back up. > >Your methods have serious problems. No, it doesn't. You keep putting statements like that in here but you have yet to point out a single actual real problem. [....] >> You just bark some new claim at the >>thread and assume that it will convince people. > >This is not a conflict of who knows more than the other. These >are serious matters and there is no room for pissing contests. You seem to be trying to convince people that you know stuff. But when put to the test it turns out you have them wrong. You claim there are problems with my method of doing a backup but you have yet to be able to state what this problem actually is. [....] >>The disks and computer have gotten faster more than they have gotten >>bigger. > >Sure they've become "faster". The capacity increases have stayed >ahead of processing speeds. Nope. >>Today it takes less time to image my 250G disk than it did the >>10M Winchester that was the first one I imaged. > >I don't believe imaged the Winchester. I think you dumped it to >magtape or some similar unit record medium. If you had two >drives with one dedicated for backups, then you worked for >a very rich company. Actually I did image it to another Winchester and for a very good reason. Most of the time I made an image onto tape(s). It would take several tapes to do it. [......] >>puts things back to the way they were. This means that if the system was >>broken on a given day, that exact situation is recorded on the back up. >>An earlier back up would have the system as it was on some day before >>things went wrong. This is exactly what you want back ups to act like. >>They are complete pictures of the system on a given day. The restore >>process lets you put things back as they were. The repair process is how >>you make the system correct. > >Both steps involved making crucial backup decisions. YOu have to >make these decisions when you design your backup process. This is not correct. The more decisions you make at that time, the more likely it is you are making an error. The purpose of a backup is to be a complete and accurate record of how things were. > You >cannot tell when the system got infected unless it's a poorly >designed virus. YOu could have been saving the virus on each >and every backup tape. This implies that you have no clean >system backups. This would suggest that the virus was there at install time. That is unlikely. You are again mixing the subject of repair with that of making a backup. A back up is a record of how things were. To repair a system is to make it correct or at least workable again. > The repair process and restore process has to >be done at the same time. Both "steps" have to be done >with the same action and cannot be separated as you seem >to claim here. No, I have never claimed this. You have gotten this wrong too. To restore a system means to put it back as it was. To repair it means to make it right. The repair needs to have the backups and the restore needs to have the backups but they are two different things. > >/BAH -- -- kensmith(a)rahul.net forging knowledge
From: krw on 3 Mar 2007 11:27
In article <esbpq1$8qk_005(a)s977.apx1.sbo.ma.dialup.rcn.com>, jmfbahciv(a)aol.com says... > In article <MPG.2052091685c10ec298a03a(a)news.individual.net>, > krw <krw(a)att.bizzzz> wrote: > >In article <es928h$8ss_001(a)s1006.apx1.sbo.ma.dialup.rcn.com>, > >jmfbahciv(a)aol.com says... > >> In article <es829g$2hl$2(a)blue.rahul.net>, > >> kensmith(a)green.rahul.net (Ken Smith) wrote: > >> >In article <87fy8paqu8.fsf(a)nonospaz.fatphil.org>, > >> >Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: > >> >>kensmith(a)green.rahul.net (Ken Smith) writes: > >> >>> >ls -lu > >> >>> > >> >>> I assume you had a point. > >> >> > >> >>I think his point is that access time is part of the metadata > >> >>that accompanies the file. > >> > > >> >It is not stored into the data part of the file. The file's sectors are > >> >not rewritten so there is no change to that part. I believe that it is > >> >the time you close the file and not the time you opened it that actually > >> >ends up stored BTW. None of this matters to the backup method I > >> >suggested. > >> > > >> > > >> > > >> >>So we have 3 cases: > >> >>- If it doesn't change the last-accessed time, then the "last- > >> >>accessed time" is in fact a falsity; > >> >>- If it changes the last-accessed time and stores the new access, > >> >>then the restored file will not be what it was a backup of; > >> >>- If it changes the last-accessed time but doesn't store the new > >> >>time, then the file in the backup is not identical to the > >> >>filesystem that it is a backup of. > >> >>All three of these are unsatisfactory. Therefore I contend that > >> >>this field is indeed not a useful field when it comes to considering > >> >>the behaviour of backups. > >> > > >> >No, this is all silly. The backup I have been refering to is not cover in > >> >the cases in your list. What I suggested was a complete image of the > >> >drive. > >> > >> That has the problem of also preserving the bad spots of the disk. > > > >Modern disks don't show their "bad spots" to the system. > > I'm assuming that this housekeeping moved into the smart > controllers. The disk drive itself. > > They're > >replaced from a cache of hidden sectors as they fail. This doesn't > >mean it isn't possible to lose data when one fails though. > > So what does a bit-to-bit copy of the physical mean? Bit-to-bit > implies all bits, including the ones covered by the error handler... > doesn't it? Any bad sectors are mapped out so they don't get copied. They no longer exist. In fact one should never see a bad sector on a disk. If you do, throw it away. The spare sectors have been used up and data sectors (the ones you paid for) are being used for replacements. This indicates a severely damaged drive. Drives today use LBA (Logical Block Addressing). When a sector starts failing (retry threshold exceeded) the drive moves the data on that sector to a spare/reserved sector (hopefully) close by, then points to the new sector and marks the old as bad. The replacement sector is mapped to be in the same logical position as the one it replaced, even though it is not physically adjacent. When a sector- for-sector copy is done to another drive (for instance) sectors are copied from the source in logical (not physical) order to the target (where they often end up in physical order). > Oh...were they using the term incorrectly again? Words change meaning, levels of indirection are thrown in, confusion reigns, Dimbulb is wrong (and swears a blue streak to prove it). Nothing ever changes. -- Keith |