saving a gnucash data file

[Mike or Penny Novack]

>
>A nightly (or whatever) backup is not the only reason for taking a
>backup.  If one is about to do something and one is not sure of the
>outcome (import some QIF data for example) one may want to take a
>backup at that point in case the import goes wrong.  To satisfy this
>one needs an 'on demand' backup.  How does one do this when using
>mysql?
>  
>
Agreed -- if you were wanting to make several global changes during the 
same (system) backup interval you might want separate backups in 
between. But this again is an "experience" issue because one of the 
major sources of "fun" during my working days was when there was more 
than one backup and subsequently the wrong one used for a restore (date 
of creation, possibly also used in the name of the backup, not unambiguous).

>It is not only an issue of the data being stored on another machine.
>On my Ubuntu PC the mysql databases are stored in /var/lib/mysql,
>which is not something that a 'user' (spouse) as opposed to sysadmin
>(myself) knows.  In addition the gnucash db is not just a file there.
>One cannot back it up merely by copying a file.
>
>  
>
This part of it I don't understand. Probably because again I don't 
necessarily think of backing up a database as copying ONE file. Mind, 
working with (manipulating) either the "flat file" backup of a database 
or working with just one of its components (say enlarging the space of 
an index component) also the sort of thing I used to do. But obviously 
you CAN copy a database in one operation (you can copy the whole darned 
disk it resides on for example --- though of course in my working days 
some of "my" databases took up multiple drives -- even if accessed as a 
flat file*).

I agree that users might not know where their data "lives". But my 
experience tells me that users in this situation will not be making 
backups on their own. After a minor disaster I've supplied the Secretary 
of our organization with an external USB drive and told her "I could 
have given you just a moderate sized thumb drive and told you to back up 
just the organization's files -- but here's something big enough you can 
simply copy your entire "user data area" each time". ONE operation and 
guaranteed to catch all files no matter where she put them (she's not so 
advanced as to know how to set up write access to other areas).

So what I am really saying is that if users lack the ability to do their 
own backups (and something is needed to handle it for them) then this 
problem isn't going to be limited to one application and so calls for a 
global solution, not an application by application solution. With regard 
to the issue of backups in between, that's an argument in favor of  "on 
the fly" incremental backup -- which isn't going to care that the 
database is represented by one physical file or N of them. But of course 
the downsides of on the fly incremental backup are:
1) Time --- this chews up computer time while the user is on rather than 
say running in the wee hours of the night.
2) Hard to correctly restore except "last version" (hard for a 
relatively unskilled user

Michael

* One of the largest could be accessed "direct access" with data 
component and two levels of indices (three physical files) OR just the 
data component accessed "sequentially" as if it were an ordinary flat 
file -- but that data component was big enough to fill three mainframe 
drives.