Re: backup takes too long

In article <3385ED56.526B@bit-net.com>, Doug McAllister <abcd@bit- net.com> writes >Ontape. (There is no way you can back up a 200 gig database in 3 hours >with Ontape but I can do it with OnArchive). Doing an archive to disk is Agreed - the fast tape drive I have ome across is a SUn DLT 4000 which can handle 14,400 Mb/s. >a great idea as long as you have enough disk to support it. I had a >client who would archive to disk and then use UNIX compression against >the resulting file. This worked fine but he had to de-compress his files >before he could restore. What happens if both the disk with the archive on it and the disk with the root dbspace on it both fail? Then you lose data, I'd rather have everything on tape where I know it is safe. >Lastly, if you use something like unloads to do the archiving, the >engine will never recognize the fact that it has had an 'archive'. >During an archive the engines cleans up things like logs and records the >archive in the reserved pages to make restores easier. This then will >let you know exactly which log files are needed for a roll forward. > Agreed, also on table unloads you do not get a consist view of the database. You get table 1 as it was at 14:00. table2 at it was at 14:10, table 3 as it was at 14:20. After restore the tables are out of synch. Great I posted a creidt to the credit notes table crediting myself with 1000,000 dollars and posted a debit to the debits table of 1000,000 dollars. The backup got the new version of the credit notes table and the old verison of the debits table. After restore I have +1000,000 dollats and you lost....NOTHING!!!!! >Doug McAllister >ex-Informix engineer -- David Williams