Preface -- Eric, let me tell you I'm wondering about the tone of your replies which IMHO is in no way suitable to my (again) IMHO valid questions -- which are on topic for this list anyway.
In case of requests you aren't able to answer authoritative or competent you'd better behold -- instead of offending people just to mask you cannot answer. I'm in no way questioning your knowledge in whole, yes, in general I do welcome and value your input very much. Nevertheless, I did comment your reply, and there is some offence, of cause. Which you should be able to withstand ... Thanks for your time, -Thomas On 2002-07-15 18:37 +0200, Eric Hildum wrote: > If data has been flushed, the compare will fail. Therefore, you have a > problem. The only problem is, there isn't a compare possible ... no problem with the backup itself, first hand. > I really do not understand what you are thinking. You are apparently asking > how to tell if you have a problem. I have answered that question repeatedly. I might have missed the answer ... question is, does E'rage in fact withhold from flashing to disk while one of its databases is being backed up by Retrospect. And, how about the set of E'rage databases, which seem to be relational (Database <-> Messages). None of those questions have ever been answered, and there is hardly any information available to the public about E'rages methods of database access. > You apparently seem to think a backup should always succeed, no matter what > the circumstances. Once verified hardware and system is in good shape, apps behave, there is hardly a need for a compare at a regular basis. And, in case of five or seven independent backup sets, a single failing backup is no problem, either. > That simply does not happen in the real world. Files get > opened and changed. Backup media has glitches. Things happen. Retrospect has > some of the best reporting and handling of these and other types of problems > that I have seen (and I have seen a lot of them). Not that I'm advocating against Retro in any way, but I cannot understand your enthusiasm as there are far better solutions available, open data handlers yadda yadda -- unfortunately not suited to Mac-centric small biz, and NT based anyway. > Now, usually, a data inconsistency error will affect one or a few files. > Normally, the easiest solution to this problem is to simply rerun the backup > after closing whatever application is updating the file. In the case we are > discussing, quitting Entourage is usually sufficient. I'm aware, naturally at this moment I'm playing that traditional game. But why not advance ... If E'rage would always leave its databases in consistent state, with both E'rage and Retro properly locking, there would be no reason to stick to just back up quiet networks and disks. If please somebody could answer authoritative ... > If you have repeated problems, you can follow the other recommendations here, > such as starting with no background tasks or mounting the drive as a target > disk on another computer. judging from this list, I have almost zero problems. Maybe there is a reason ... > If you wish to talk about large transactional databases that are constantly > updated, I'll refer you to Oracle - that type of database is rather > different than a simple mail system database, At this stage, I'm wondering why there are no answers available in regards to my simple E'rage database :-/ > and does require solutions dedicated to backing up that type of database. > However, that is another mailing list. Well, an Oracle backup related list obviously won't help that much -- any pointer to an E'rage backup related list is welcome ;-) -- Thomas Schierle, Munich, Germany PGP key [DSS/DH] 0xA23CDA1D available at various public key servers -- To unsubscribe: <mailto:[EMAIL PROTECTED]> archives: <http://www.mail-archive.com/entourage-talk%40lists.letterrip.com/> old-archive: <http://www.mail-archive.com/entourage-talk%40lists.boingo.com/>
