Difference between revisions of "Backup"

From GnuCash
Jump to: navigation, search
m (Related Files: Fixed forward vs. backslash errors with respect to paths for Linux and Windows.)
m (minor rewording to add clarity)
Line 11: Line 11:
 
;XML (default): GnuCash makes local backups for you every time it saves your file. You must save your file (by clicking the Save button or using Autosave functionality in the preferences). It does this by renaming the previous version of the file with a date-time-stamp and a new .gnucash suffix. For example, if your data file is named MyAccounts.gnucash, one of the backups might be named MyAccounts.gnucash.20140131150812.gnucash.
 
;XML (default): GnuCash makes local backups for you every time it saves your file. You must save your file (by clicking the Save button or using Autosave functionality in the preferences). It does this by renaming the previous version of the file with a date-time-stamp and a new .gnucash suffix. For example, if your data file is named MyAccounts.gnucash, one of the backups might be named MyAccounts.gnucash.20140131150812.gnucash.
  
;SQL: GnuCash saves changes to sql data stores automatically as you go. For this reason, there are no backup files for the SQL. Even though there are no automatic backup files generated when using SQLite backend, GnuCash will still generate .log files with changes. While it might possible to replay .log files on top of an sql book, this is not officially supported. One option, in case of data loss, would be to convert the sqlite book to xml and replay the transactions log on top of that and then re-save the file in SQLite. More info in the related [https://bugzilla.gnome.org/show_bug.cgi?id=795393 bug].
+
;SQL: GnuCash automatically saves any changes to the sql data stores as you work on your book. For this reason, there are no backup files with the SQL backends. Note that, even though there are no automatic backup files generated when using SQLite backend, GnuCash will still generate .log files with changes. While it might possible to replay .log files on top of an sql book, this is not officially supported and in some cases may even have adverse effects. One option, in case of data loss, would be to convert the sqlite book to XML and replay the transactions log on top of that and then re-save the file again with SQLite. More info in the related [https://bugzilla.gnome.org/show_bug.cgi?id=795393 bug].
  
:;SQLite3: You should use a timed backup program to copy your account file in some way.
+
:;SQLite3: You should use a timed backup program to copy your account file in some way, or make manual file copies.
 
:;MySQL or Postgresql: You should perform backups on the database in accordance with the recommended best practices appropriate to the server. We're not competent to advise you about this beyond recommending that you make backups.
 
:;MySQL or Postgresql: You should perform backups on the database in accordance with the recommended best practices appropriate to the server. We're not competent to advise you about this beyond recommending that you make backups.
  

Revision as of 07:28, 12 April 2019

Introduction

Backing up your GnuCash data is important to protect and secure your financial data from potential equipment failure or data corruption.

GnuCash does not directly provide back up services for this type of failure. Recovering data in the event of equipment failure depends on having a robust backup process that includes offsite storage of up-to-date copies of your data. You are strongly advised to implement such processes.

GnuCash Data Files

Determining what are the GnuCash data files depends on the type of backend used to store the book information.

XML (default)
GnuCash makes local backups for you every time it saves your file. You must save your file (by clicking the Save button or using Autosave functionality in the preferences). It does this by renaming the previous version of the file with a date-time-stamp and a new .gnucash suffix. For example, if your data file is named MyAccounts.gnucash, one of the backups might be named MyAccounts.gnucash.20140131150812.gnucash.
SQL
GnuCash automatically saves any changes to the sql data stores as you work on your book. For this reason, there are no backup files with the SQL backends. Note that, even though there are no automatic backup files generated when using SQLite backend, GnuCash will still generate .log files with changes. While it might possible to replay .log files on top of an sql book, this is not officially supported and in some cases may even have adverse effects. One option, in case of data loss, would be to convert the sqlite book to XML and replay the transactions log on top of that and then re-save the file again with SQLite. More info in the related bug.
SQLite3
You should use a timed backup program to copy your account file in some way, or make manual file copies.
MySQL or Postgresql
You should perform backups on the database in accordance with the recommended best practices appropriate to the server. We're not competent to advise you about this beyond recommending that you make backups.

As noted above, it is strongly recommended that whatever backup plan you use includes a provision for offsite backups. Imagine a fire in your home. A good option is one of the many cloud storage services like DropBox, Google Drive, or Carbonite. Those are just popular examples; there are dozens of such services, and we can make no recommendation of one over another.

There is a free 3rd party tool for creating GnuCash backups called BackupGnuCash. See Published_tools.

Related Files

Of course, you should save your actual data files, although it is up to you whether you save the backup and log files (.gnucash or .xac, .log). See above for more on the subject.

In addition to the actual data file, however, there are a number of files that store your preferences, user interface settings, and saved reports. It is advisable to back these resources up as well.

Configuration Locations identifies the OS-dependent locations of all the different files, as well as their names.

Additional information you need to save includes general configuration data, preferences data, theming data, and online banking settings.

General Configuration data
Linux: HOME/.gnucash - most of your preferences, adjusted report settings, column withs, window positions, etc.
Windows: HOME\.gnucash
MacOS: HOME/Library/Application Support/Gnucash
Preferences data
Preferences from Edit->Preferences (like history, sign reversals, auto save interval, etc.) are stored using GSettings (for GnuCash 2.6 and newer) or GConf (for GnuCash 2.4 and older).
  • For GSettings settings:
  • Linux and similar: GSettings uses dconf as backend. You can use the dconf tool to dump all the preferences:
dconf dump /org/gnucash/
  • Windows: Gsettings uses the Windows registry as backend. You can make a backup of the HKEY_CURRENT_USER\Software\GSettings\org\gnucash\ registry key using the regedit command (Registry Editor).
  • MacOS: GSettings uses the system's native defaults. You can use the defaults tool to dump all the preferences:
defaults read --app Gnucash
  • For GConf based settings:
The GConf settings are stored in HOME/.gconf/apps/gnucash/
Online Banking data
If you are using AqBanking online banking, the stored settings are placed in a specific folder.
  • Linux and MacOS:
HOME/.[aq]banking holds your online banking settings. In older versions it was named .banking but .aqbanking is the current name.
  • Windows:
HOME\aqbanking
Theming Data
If you made changes to the GTK configuration (settings.ini or gtk.css) or have installed custom themes and/or icon themes you may want to back up the contents of the following directories as well: GTK_DATA_HOME, GTK_CONFIG_HOME, USER_CONFIG_HOME/themes and USER_CONFIG_HOME/icons. For Gnucash 3.x GTK3 or older versions GTK2 have more info on when these directories are used.

Restoring

Restoring a data file is simply a matter of removing the defective file and renaming one of the backup files to that, then starting Gnucash or using File>Open and selecting the file from the File Chooser.

To restore from an offsite backup, just copy the remote file back into the directory where the original is.