I have encountered a few situations recently that resulted in data loss because a backup of the Alteryx Server wasn't available. I can't stress enough the importance of regularly backing up your server. This article, the first of two-part series, will cover some options and best practices to ensure you have the necessary backups available in the event they are needed. Part II will focus on the embedded MongoDB instance provided with the Alteryx Server install. If you are utilizing a user-managed MongoDB instance, please refer to MongoDB's documentation for backup and recovery procedures at https://docs.mongodb.org/manual/administration/backup/.
Let's go over some widely accepted best practices for backing up servers and databases:
Schedule Regular Backups - Backing up consistently on a scheduled basis is key to ensure you minimize data loss and downtime. I recommend backing up nightly during non-peak hours to minimize potential impact to users and for the minimal amount of data loss in the case of a crash or another failure. If backing up nightly isn't feasible, scheduling weekly backups is also an option. The important thing is to set a regular schedule.
Keep Historic Backups for a Defined Period - Sometimes the unexpected happens and a backup fails, becomes corrupt, gets lost/deleted, or the issue isn't noticed immediately (causing the problem state to be present in the backups). Having historic backups available helps ensure you have a backup available, and allows you to choose one created before the issue began.
Store Backups on Network or SAN Storage - Storing your backups on the same server where the data resides runs the risk of those backups not being available during a failure event. Let'sconsider what happens when your server suffers a disk failure. If the backups are stored locally on that disk, then they are gone too, making recovery impossible. However, if your backups are stored on the network they would not be impacted by a failure event on the server.
Keep a Copy of the Backup Off-Site - This falls along the same lines as above. If the only backups are on a file server in the same data center as the Alteryx Server, and that data center suffers a disaster, you will lose both your server and your backups. Keeping an additional copy offsite will allow you to bring the server back up in the Cloud or at another data center if need be.
Validate your Backup Files - You should periodically check to ensure your backups are occurring successfully, and confirm that the backups are valid and usable. There is nothing worse than putting a backup process in place and then finding out after a failure occurs that the backups stopped working 6 months ago or that all of your backups aren't usable.
Practice your Recovery Procedures Regularly - Recovery drills allow you to become familiar with the restoration process and the amount of time needed to return to a fully functional state in the event of a disaster. Practice is also proven to reduce the occurrence of mistakes, and can save valuable time. I recommend running a recovery drill quarterly or bi-yearly.
Keep in mind that, in most cases, backing up the entire server including the OS and all data isn't necessary. In fact, it can actually significantly increase the average time to restoration. Instead, I would recommend backing up only the critical data and configuration files for the server. This is because it is significantly faster to clean install the server and necessary software, and then restore the backed up data/configuration than it is to restore the entire server. This is especially true in the case of virtual servers, as deploying a new virtual server takes minutes in most cases. These limited backups can also reduce the time it takes to complete and validate the backups and reduce the storage needs/costs involved in keeping those backups.
Part 2 - Alteryx Server Backup & Recovery Part 2: Procedures
