Skip to content

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:

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.

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.

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 can 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

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

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 cause older backups to be pruned (deleted) as per the number of backups to keep setting.