The *.xml.bak files that are created correspond exactly to the *.xml files
which are written. Most of the *.xml files are small(ish), including the
top-level file PROJECT_NAME.xml. The really big file, normally, is
PROJECT_NAME/ccp/nmr/Nmr.xml, and hopefully its backup file is also big!
Wayne
On Wed, 28 Mar 2007, Johnny Eugene Croy wrote:
> Wayne,
>
> I was a bit too slow on the email, but I wanted to offer a suggestion
> to the large backup file problem. Can the backup files be
> compressed? Maybe a way around the large backup file size would be
> to have analysis make the backup and then store this file as a
> tarball archive that can be accessed when necessary.
>
> Also, when backups are made which files are created? Is it only the
> *.xml.bak file? I don't think so because these files are only KB is
> size...I assume there is more to the backup than this.
>
> - Johnny
>
> On Mar 28, 2007, at 10:35 AM, Wayne Boucher wrote:
>
> > Yes, the problem with the auto-backup is that if you don't notice the
> > problem in time then it doesn't do much good in any case. We
> > purposedly
> > didn't allow multiple backups (that would take a lot of disk space)
> > but
> > maybe we need to start thinking of doing that. Perhaps even allowing
> > auto-backups to a remote disk.
> >
> > Wayne
> >
> > On Wed, 28 Mar 2007, Martin Christen wrote:
> >
> >> Thanks for the detailed explanations, Wayne.
> >> You were right again, I also had to recover
> >> the Analysis.xml file from the backup.
> >>
> >> Everything seems to work fine now but just in case,
> >> I kept a copy of the corrupted project folder.
> >>
> >> As a sidenote, I don't use the automated backup feature.
> >> I ran into the problem that it would make a backup at
> >> an undesirable time (for example, I try something that
> >> goes wrong and right after that, the autobackup decides that
> >> it's time to save - oops!), so I just make regular copies
> >> of the project folders manually instead.
> >>
> >> Thanks again!
> >>
>
|