Where does Gnucash save it backup files when using mysql data source

[AC]

On 2015-07-05 12:34, David G Hamblen wrote:
> 
> 
> On 07/05/2015 10:21 AM, Colin Law wrote:
>> On 5 July 2015 at 10:47, L. D. James <ljames at apollo3.com> wrote:
>>> When I first started using Peachtree, as far as I know, it was a
>>> bunch of
>>> local files very similar to the way Gnucash started out. Eventually they
>>> incorporated a database engine.  It's a very powerful engine.  I can
>>> research and give you the name of it.  The Linux version of the
>>> engine is
>>> extremely expensive.
>> If that comment is in answer to my request for examples of
>> applications that use mySQL and do database backups within the apps, I
>> am not particularly familiar with Peachtree but I don't think it uses
>> mySQL.  I think it uses the Pervasive database which is a very
>> different beast to mySQL.  A big difference I think is that Pervasive
>> is intended to be embedded within an app, whereas mySQL uses an
>> external server over which gnucash has little control.
> 
> I use Peachtree extensively at work (GC at home) and yes, Peachtree uses
> Pervasive, but their backups are simply a zip file of the entire data
> directory.  They've got a Windows script which sets up the equivalent of
> a cron job to do the zip backup to anywhere (I automatically backup to
> an off-site server every two days).  So doing a compressed xml export as
> previous posters have suggested would be good.  (I do that manually
> about once a month at home - SaveAs, followed by reopening the mysql db.)
> ...
> (snip)
> ...

The Pervasive engine uses a file storage mechanism similar to flat file
databases like sqllite.  That's why the backup process can be a simple
zip archive.  This is by design since the Pervasive engine is intended
to be embedded in software without necessarily requiring a separate
application/server installation like would be required with MySQL,
Postgres or other engines (except sqlllite which is also an embedded
type of database).  This method of backup doesn't work with other
database engines because they use files on disk as a type of virtual
disk drive, writing data in various places within the file as the engine
needs.  The file is never in a consistent state unless the database has
been closed and flushed because of the random access nature of the files
(no declared internal structure in the file like flat file databases).

The argument about performing a "Save As" on a Gnucash database hosted
on a database engine instead of the XML storage is just the data
integrity.  Gnucash must be able to signal other clients that they must
complete all transactions and close out their connections prior to the
export otherwise there is no way to guarantee a write doesn't occur
during the export (this would be a full database lock but it's
inefficient and time consuming especially as the number of records
grows).  There are better ways of doing this but they would have to
happen outside of the Gnucash client.