Automate Your Alteryx Server Backups

Your Alteryx Server is the beating heart of your analytics. Ensuring its safety through regular backups is a critical part of responsible data management. In this guide, we'll walk you through the steps to create an automated backup process for your Alteryx Server, safeguarding your workflows from unforeseen events.

This article is not meant to rigidly define a backup plan, but rather act as a jumping-off point for your unique needs.

Article Outline

1. Resources
2. Making a Plan
3. Create the Backup Manually
4. The 3-2-1 Backup Rule
5. The Backup Script
6. Parameters Explained
7. What's Happening - Check Alteryx Service
8. Monitor the Backup
9. Schedule Regular Backups
10. Create-AlteryxBackupTask.ps1
11. Testing the Backup
12. Document the Backup Process
13. Conclusion

Resources

Code examples below are taken from these scripts. I am assuming that they will be saved to `C:\ProgramData\Alteryx`.

• Create-AlteryxBackupTask
• Backup-AlteryxServer

Making a Plan

How is your Alteryx Server hosted, on bare metal or on a hypervisor as a VM? These kinds of questions will help drive the technical details of your backup plan.

Some organizations rely on taking snapshots of the disk of a running server. Alteryx uses MongoDB, an online transactional database that needs to be stopped prior to creating a backup. While the service is stopped, scheduled workflows will not be triggered and the gallery is inaccessible. Because of this, it's best to perform a backup during a defined maintenance window.

Not all snapshots are created equally; it's important to stop the Alteryx service to take a backup during a regularly scheduled maintenance window. The resulting backup can then be picked up by a backup agent or the disk snapshot.

If your organization has a backup team or person, that is responsible for managing the backup infrastructure/tools, now is the time to ask for their input. They may have a backup agent/service that already runs on the server.

Create the Backup Manually

Before we can backup Alteryx, we need to know where it's installed. By default, and in our example, Alteryx is installed in C:\ProgramData\Alteryx. We'll be calling the AlteryxService.exe directly to create the backup, but before we can create the backup we first need to stop the Alteryx service.

# Disabling service so it isn't accidentally started
Set-Service -ServiceName AlteryxService -StartupType Disabled
Stop-Service AlteryxService


Once the service has stopped, creating a backup is as easy as ...

C:\ProgramData\Alteryx\bin\AlteryxService.exe
emongodump=C:\Users\Alteryx\Desktop\MongodbDump_2023-10-04

This gets us a backup of the MongoDB, but we still need the RuntimeSettings.xml to be able to successfully restore the backup.

Copy-Item -Path C:\ProgramData\Alteryx\RuntimeSettings.xml -Destination
C:\Users\Alteryx\Desktop\MongodbDump_2023-10-04

Oh, and be sure to start the Alteryx service now that the backup is complete.

# Enabling the service to be automatically started
Set-Service -ServiceName AlteryxService -StartupType Automatic
Start-Service AlteryxService


So that's the manual way to create a backup. Let's look at scripting that and scheduling that to run during a maintenance window.

The 3-2-1 Backup Rule

As a rule of thumb, you should have 3 copies of your data, on 2 different media types, and keep 1 copy offsite.

In our example, we have two servers; an Alteryx Server and a remote file server. The IT team is small, they don't have a person focused solely on backups. The IT engineer has a file share that is backed up; she said if we get it there, she'll make sure that it gets backed up.

The Alteryx Server and the remote file server are likely on different storage. If they're hosted in the cloud, they almost certainly are. The backup of the remote file server is also likely to a different storage media. e.g. tape/s3/blob

For those of your keeping score, the Alteryx Server is the first copy, the remote file server is the second copy, and the backup of the remote file server would be the third copy.

I'm deliberately going to gloss over Recovery Point Objectives and Recovery Time Objectives. Those are beyond the scope of this article, but it is worth considering how often your workflows are changing when scheduling backups. For our example, we want to keep a copy of the backup locally on the Alteryx Server, and several copies of the backup on the remote file server.

The Backup Script

The Backup-AlteryxServer PowerShell script has been parameterized so you can easily customize it for your environment. I saved the script to C:\ProgramData\Alteryx\Backup-AlteryxServer.ps1.

The main parameters to update are the paths for the local and remote backups and how many copies it should retain.

param ( 
    [string]$dest = "C:\Temp\MongoDB-Backup", 
    [string]$destRetention = '1', 
    [string]$archive = "\\NAS.DOMAIN.COM\Backups\Alteryx-Node1\MongoDB-Backups", 
    [string]$archiveRetention = '4', 
    [string]$dbPath = "C:\ProgramData\Alteryx\Service\Persistence\MongoDB", 
    [System.Collections.ArrayList]$fileList = @( 
        "C:\ProgramData\Alteryx\RuntimeSettings.xml" 
    ) 
) 

Parameters Explained

As configured, our Alteryx Server will created a backup of the MongoDB and RuntimeSettings.xml locally in the $dest folder, C:\Temp\MongoDB-Backup. This directory, named with a timestamp, contains the log file; e.g. MongodbDump_2023-10-04-23-00 The server will then create a compressed archive of the local backup that it will save on the remote file server, $archive.

By default, it will retain the backup and log for $destRetention, (1) day. It will retain remote archives that are less than $archiveRetention, (4) days old. If the script is run multiple times in one day, it will create a new backup each execution, rather than overwriting an existing one.

What's Happening – Check Alteryx Service

Like we did earlier, we need to make sure the Alteryx service is stopped. Once stopped, the script can create the export. Once complete, we'll restart the Alteryx service before creating the compressed remote archive to minimize the downtime.

At the end, it will prune any backups, logs, and compressed archives that are outside of the retention window.

Note About Backup Agents

If your organization has a backup agent, you might not want to create the compressed archive on the remote file server. Since the script is meant to be customized, you're free to disable that function.

Monitor the Backup

Periodically review the backup log to ensure that backups are running smoothly. If you have an IT operations team, work with them to configure their monitoring and alerting systems to be notified of any backup failures or anomalies.

As mentioned earlier, this script is intended to be a jumping off point for tailoring to your organization. It could be extended to make API calls to ServiceNow, create custom Windows Event Log entries, publish a message to Slack, and etc.

Below is a condensed example of the logs from a successful backup.

"Now","ComputerName","Output"
"10/04/2023 23:00:13","USCE-ALTX-D01","Starting MongoDB backup"
"10/04/2023 23:01:03","USCE-ALTX-D01","MongoDB backup completed"
"10/04/2023 23:01:03","USCE-ALTX-D01","Starting Alteryx Service"
"10/04/2023 23:01:37","USCE-ALTX-D01","C:\Temp\MongoDB-Backup\MongodbDump_2023-10-04-23-00 took 9 seconds to compress."
"10/04/2023 23:01:37","USCE-ALTX-D01","Removing backup MongodbDump_2023-10-03-23-00"
"10/04/2023 23:01:37","USCE-ALTX-D01","Removing archive \\NAS.DOMAIN.COM\Data\Alteryx\MongoDB-Backups\AlteryxBackup-2023-09-29-23-00.zip"
"10/04/2023 23:01:37","USCE-ALTX-D01","Ending backup script"
"10/04/2023 23:01:37","USCE-ALTX-D01","Total MongoDB backup time: 00:01:36.4873375"

The duration of the backup process directly correlates with the size of your MongoDB. Note that on our dev server it took less than two minutes to complete, including stopping and restarting the Alteryx service.

A server with a 13GB database should take less than 5 minutes to export, while a one with a 63GB database full of content may take nearly an hour. The compression time will depend on how fast the connection is between your servers.

Before moving onto scheduling the backups, run a couple manually to get a feel for how long they take to complete.

Schedule Regular Backups

Since Alteryx needs to be stopped to take a backup of its database, this would ideally be performed during a nightly maintenance window, 11:00 PM - 2:00 AM.

Consider what other maintenance may be scheduled, like Windows Updates. In our example, the IT team schedules a full disk backup on Saturday night, and Windows Updates for early Sunday morning.

Also, review any scheduled workflows for conflicts with the backup time. A running workflow can prevent the Alteryx service from stopping and could require force-stopping the process. it's a best practice that the service is cleanly stopped before a backup.

Create-AlteryxBackupTask.ps1

Create-AlteryxBackupTask is a helper script that is used to create the Scheduled Task in Windows that will run the backup job. In order to be able to create the scheduled task, and modify the security policy, this script must be run as an administrator.

I saved my backup script that the scheduled task will run as "C:\ProgramData\Alteryx\Backup-AlteryxServer.ps1", the default defined in the parameters.

The remaining customization to do immediately follows the parameter block. By default, it's set up to run on weeknights at 11:00 PM.

# # Schedule the backup here # #
#
# # Weeknights
$taskTrigger = New-ScheduledTaskTrigger -Weekly -WeeksInterval 1 -DaysOfWeek @('Monday','Tuesday','Wednesday','Thursday','Friday') -At 11pm


# # Nightly
# $TaskTrigger = New-ScheduledTaskTrigger -Daily -DaysInterval 1 -At 11pm

This script will prompt the user for the credentials of the service account that the Scheduled Task will use when it runs the Backup-AlteryxServer script. By prompting the user for a credential, the password for the service account is not inadvertently persisted to disk in a script or shell history.

Next, the script will lookup the Security Identifier (SID) of the service account and grant it permission to 'Log On as a Batch Job' in the Local Security Policy.

Testing the Backup

Many enterprises have Disaster Recovery exercises where they test the recovery plans for their applications. Testing like this requires a sandbox license, as the backup will be restored and running at the same time as the production server.

Performing a server restore is outside of the scope of this article. For more information, please see the Alteryx Server Host Recovery Guide.

Document the Backup Process

Documentation will set you free! No, seriously. By maintaining comprehensive documentation of your backup procedure, anyone should be able to cover for you while you're relaxing on a beach.

Pertinent details to include would include the backup schedule, the service account running the script, pertinent paths, log location, and retention. This documentation is invaluable, you never know...

Conclusion

Creating a backup strategy for your Alteryx Server is a critical task that ensures the safety and integrity of your workflows. By using this article as a guide, you'll have created a simple, highly customizable, backup plan; one that's automated, scheduled, and hopefully monitored. 😉

Remember, it's not just about creating backups, but also about regularly testing and verifying them to guarantee their effectiveness. If you have any questions about your Alteryx Server backups, we'd love to help answer them.

Contact us at alteryx@continuus-technologies.com