Operations backup form¶

backups form

The Backup form is used to view and control automated system backups.

Authorization Roles required¶

Making changes to backup is only available to Users with the following roles:

Full access

System operations

Read only access

Business administration
Business administration - restricted
System operations - restricted

How to access backup¶

Backups are accessed in the following ways:

From the Server operations navigation drawer Backup item

How backup works¶

AyaNova can automatically back up to the local file system once per day at a selected time.

The backup form is where you can configure how the backup works, perform a test backup and download backups for offsite storage.

The backup form is available to any User with the Operations Role selected and is located in the navigation panel under Server Operations -> Backup

It is not necessary to use the AyaNova automatic backup job if you already have a backup system in place for your PostgreSQL server, however the attachment files would still require some method to back them up independently if the AyaNova automatic backup job is not used.

Backup format¶

AyaNova creates two backup files when a backup is processed, the files are named based on date and time.

The attachments backup file starts with "at-" in the file name followed by a timestamp and is a standard zip archive of the attachments folder.

The database backup file starts with "db-" in the file name followed by a timstamp and with the extension ".backup". AyaNova uses the pg_dump PostgreSQL utility to backup the database and uses the -Fc command line switch to create a "custom" format backup which is compressed.

Do I still need to backup even if I use AyaNova as a subscription service?¶

Yes! Accidents can happen. You must set up a backup routine and regularly download a copy of your backup for safe storage in your own custody.

We strongly recommend you read and follow the best practices outlined here to ensure the safety of your data.

We do not maintain a separate copy of your backup; it is your responsibility to ensure you have a recent copy of your backup available to provide to us should it ever be required to be restored.

How to download your backup¶

Your backups are displayed on this backup form in a table and if you have sufficient Roles assigned you will see a download icon beside each backup file listed enabling you to download the backup.

Be sure to download both the database and attachment backup files.

Note that you may not see an attachment backup file if there are no attachments in AyaNova but you will always see a database backup file unless there is a problem.

We recommend downloading and keeping multiple copies of your backup in a safe location.

Failed backup¶

The most important step to detecting failed backups is to ensure several users are subscribed to the Backup status notification subscription. This is the best way to detect a failed backup in a timely manner and several people should be subscribed to this event to ensure it doesn't get missed.

Aside from the notification, the backup form itself shows useful information to detect the state of the backup:

A backup file is almost always generated; even in the case of a total failure to backup a zero byte file will be generated. AyaNova can not always detect if a backup failed but if it's zero bytes that is a certain indication and that backup will display as red in it's row in the backup files table as you can see in the image above.

Other indications of a failed backup are unsually small backup files or errors in the server log.

The only certain way to know if a backup is good is to test restore it from time to time and we recommend doing so on a regularly scheduled basis to be certain the backup is good if you need it.

Warning: Be careful about using special characters for your Postgres connection string, particularly the password and database name, we've encountered issues with the automatic internal backup failing due to a @ or $ symbol in the password. On some platforms when AyaNova attempts to run the backup utility it may fail if that operating system does not support certain special characters found in the password as they may interfere with the "shell" command called to perform the backup.

Best practices for disaster recovery¶

You should consider potential disaster scenarios appropriate to your region or the region where your AyaNova server is located. Ideally you want your backups to be stored in a location far enough away from your server to not be affected by the scope of a disaster that happens in your region but close enough at hand that you can access the backup in a timely manner to get back up and running again.

AyaNova backs up to it's own server's local drive only. This is not a full backup solution only a partial one; you also need to store copies of the backups off site from the AyaNova server in case of hardware failure, natural disaster, theft etc.

A backup only stored on the same server (or even in the same building) as the live data is no backup at all if hardware fails or a server is stolen or destroyed in a disaster.

You should regularly download the backups for storage to a secure off-site location from the AyaNova server. Also keep in mind recovery time, if the data is stored in a location that is hard to access in a disaster it will add to the time taken to recover the server and be back in business should there be a loss of data.

Subscription AyaNova service for disaster relief¶

AyaNova backups made on a self hosted Perpetually licensed AyaNova are compatible with our Subscription hosted AyaNova service and vice-versa.

If you are running AyaNova locally and lose your hardware in a disaster and have a backup available we can have you up and running quickly by restoring your data to our AyaNova subscription service platform which is available on a low cost monthly basis.

Your service business can be back up and running quickly from anywhere on the internet even if your office and server are still inaccessible due to disaster.

The data can be moved back to your own server at a later date when your office and hardware are accessible again.

Assign a staff member the Operations - restricted role¶

It's a good idea to assign a regular (non technical) staff member the System operations - restricted Authorization role.

They will not be able to make changes to the server configuration but they will be able to check important things like confirming the backup has run (for example) and be able to view the server operations log when issues arise to determine if it's time to call in the I.T. person or not.

There should always be a non I.T. User assigned with Operations - restricted role set as it is a critically important task to confirm the daily backup is operating as it should and a second set of eyes on the backup and server log is always desireable.

Backup the configuration¶

(Not applicable to Subscription AyaNova service customers)

AyaNova does not backup it's boot configuration so it is an important part of disaster recovery to keep a copy of the AyaNova server configuration if it has been modified from it's default in case AyaNova needs to be re-installed again.

10 backup rotation¶

Unless your industry has a different specific legal requirement that must be followed; we recommend the standard business practice of a 10 backup rotation system of retaining 10 copies of the daily backup.

You would download the most recent backup to a secure offsite location daily, naming and rotating them by replacing the oldest one each in the following pattern:

4 Daily backups Monday to Thursday ("Monday", "Tuesday", "Wednesday", "Thursday") 3 Weekly backups each Friday ("Friday1", "Friday2", "Friday3") 3 Monthly backups on the first of each month ("Month 1", "Month 2", "Month 3")

This means you will have 10 secure, off-site backups available in total to restore from at all times going back as far as three months or as recently as the last business evening.

The reason to keep so many backups is that there can be cases where critical data was lost but not noticed for some time, this system gives as much as three months to recover anything lost.

It is also a reasonable precaution to keep a yearly offsite backup going back as many years as is practical to store or appropriate to your business (and any potential legal requirements for your industry).

Restoring from backup¶

To restore from backup see the restore guide.

Configuration¶

Default values¶

When AyaNova is installed it sets some minimal defaults for backup. The backup time is set to 11:30PM local time, attachment files are set to be backed up in addition to the database and the backup sets to keep is set to 1 in order to prevent a scenario where excessive disk space is consumed unexpectedly.

These defaults should be examined carefully and set to values that are appropriate for your organization.

Backup time¶

Choose a time for the automatic backup when the server will not be in use by Users.

Windows server IIS Warning if you are hosting AyaNova via IIS on Windows be aware that there is a setting in IIS that will regularly restart AyaNova automatically and it must be adjusted to not conflict with the backup time and general usage.

If you're not sure then double check the IIS installation instructions Application Pool settings.

Backup attachment files¶

Attached files are stored by the AyaNova server separately from the AyaNova database in a special location in the file system.

Checking this box will cause AyaNova to also back up the attached files in addition to the database backup.

Number of backups to keep¶

Perpetually licensed AyaNova only

AyaNova Subscription service keeps one backup by default and this option is not available

The backup system will automatically remove old backups depending upon this setting. If it is set to 3 then the most recent three backups are kept.

If you are following the disaster recovery best practice policy of 10 backup rotation as suggested above then you would only need to keep 1 current backup set.

Active¶

Backups won't run if set to inactive. This is a control to turn on or off the Backup job entirely.

Backup Files table¶

This table contains the available backups on the server and provides the link to download them for off site storage.

Backup names¶

The listed backups have particular names:

The first segment of the name identifies the data in the backup file: Database backups will have "db" in their name, attachment backups will have "at" in their name. If the backup was triggered manually in the user interface it will be prepended with "manual" in the name.

The second segment is the date and time of the backup.

Attachment backups are .zip files and database backups are Postgress standard .backup files.

The Backup now menu option does exactly that: an on demand instant backup. This is useful for testing purposes or after large changes are made that you would like to ensure have been backed up. This will generate a manual backup that is not part of the normal automated backup process.

Note that this backup will still cause older backups to be pruned (deleted) as per the number of backups to keep setting.