SAS Viya Backup and Restore: new features add flexibility

1 Like

SAS Viya backup and restore has recently introduced some exciting new features that offer greater flexibility in backing up and restoring SAS Viya Environments. In this post, I will provide an overview of these features, and discuss the advantages and disadvantages of each approach. This will help you determine which backup and restore strategy best suits your requirements.

As a reminder, the tools are commonly used in three main scenarios: restoring in place, SAS Viya 4 to 4 migration, and disaster recovery. Let’s start by taking a look at the classic backup and restore functionality that we have had since SAS Viya 4 was released.

SAS Viya Application Backup and Restore

Backup with SAS Viya application backup is the default. This is the functionality we have had available since the release of SAS Viya.

A backup includes a complete backup of PostgreSQL databases, Configuration Server, and CAS metadata and data. The PostgreSQL backup and restore are performed using pg_dump and pg_restore. These utilities make a complete copy of the database into and out of the backup package. CAS data and metadata are likewise copied in full to and from the package.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

Backups can be used for disaster recovery, SAS Viya 4 to 4 migration, and in-place restores. While this method is versatile and can be used in all scenarios, it may run more slowly when working with large amounts of PostgreSQL data. Similarly, the CAS backup will be slower when the default caslibs contain large volumes of data.

Backup and Restore Using Provider-Specific Processes for PostgreSQL in addition to SAS Viya Application Backup

You can exclude the PostgreSQL data from the backup process and use the PostgreSQL provider to manage that part of the backup. To do this set the environment variable INCLUDE_POSTGRES=False in the backup configMap. A full backup excluding PostgreSQL includes a complete backup of the Configuration server, CAS metadata and data, but does not include any of the PostgreSQL databases.

The PostgreSQL database backup is managed by the PostgreSQL provider. No PostgreSQL data is written to the backup package. For more details on this approach check out this article which covers its usage on Azure using Azure Flexible PostgreSQL server. This approach can also be used in conjunction with the internal PostgreSQL server using the pgBackRest utility of Crunchy PostgreSQL.

The PostgreSQL provider must support Point-in-time restore (PITR). In addition, the retention period of the PostgreSQL backup and the SAS Viya backup should be synchronized to ensure both parts of the backup are available at the point in time selected for restoration. All backup and restore scenarios are supported, except in cases where internal Crunchy PostgreSQL is used; in these cases, only in-place restore is supported.

Both the backup and the restore process are significantly faster when using this approach. The backup PVC’s will require less storage space since no PostGresSQL data is included.

Backup and Restore Using Provider-Specific Processes for PostgreSQL and Incremental SAS Viya Application Backup

A recent addition to backup and restore functionality added the ability to incrementally backup CAS data. An incremental backup strategy involves storing only the data that has been modified since the last backup was taken. The first backup in the series is a complete backup, and the subsequent backups only store the modified or new data, which is the incremental differences. This approach helps to save time in performing frequent backups.

There are two parts to the CAS backup: the CAS metadata (permstore) and the CAS data in the default caslibs. This approach creates a full backup of CAS metadata but an incremental backup of CAS data.

To use this approach, you must:

Enable the Viya incremental backup job.
Use Provider-Specific Processes for PostgreSQL by specifying INCLUDE_POSTGRES=false

The incremental backup job, when enabled, runs every day (except Sunday) at 6 am. The retention period of the PostgreSQL backup and the SAS Viya backup should be synchronized. In addition, to perform incremental backups, a periodic full SAS Viya backup is required.

Incremental backups are supported for all scenarios except when internal Crunchy PostgreSQL is used. Again, in the latter case only in-place restore is supported. When using this approach there are significant improvements in the speed of PostgreSQL and SAS Viya backups, especially if you have a lot of data in the databases and/or the default caslibs. In addition, the volume of data stored in the backup PVC’s will be a lot smaller.

Comparison of Backup and Restore Approaches

The table below summarizes the 3 approaches.

Screenshot 2024-04-30 at 14.26.11.png

The recent changes mean that for all scenarios your backup package looks a little different. The format of the backup ID has changed. The backup ID is a date timestamp value that uniquely identifies each backup.

The SAS-BACKUP-ID of the full Viya backup is in the format of YYYYMMDD-HHMMSSF (the F as it signifies that this is a full backup). For example, 20240228-160410F

The SAS-BACKUP-ID of an incremental backup is in the format YYYYMMDD-HHMMSSF_YYYYMMDD-HHMMSSI. For example, 20240228-160410F_20240301-120310I. The incremental backup ID's first timestamp refers to the last full backup, and the second to the last incremental backup.

In both cases, YYYY represents the year, MM represents the month, and DD represents the day of the month. HH represents the hour, MM represents the minute, and SS represents the second. All times are in UTC.

For SAS Viya 4 to 4 migration and disaster recovery, you must copy all backup packages, including one full backup and all related incremental backups, from the source to the target.

Wrap Up

SAS Viya has recently been updated to improve its backup and restore functionality, providing more flexibility in how the process is managed. With the new changes, it’s now possible to perform point-in-time restores of PostgreSQL and incremental backups of the CAS filesystem. This allows for more efficient use of resources and faster processing of backup and restore. If you’re not concerned about time and resource usage, the existing backup and restore process remains a good option that’s easy to use.

I would like to thank Dawn Schrader, Penny Downey, JK Min and Scott McCauley for their valuable input to this post.

Please check out the Backup and Restore documentation for more details:

Check these related blog posts:

Find more articles from SAS Global Enablement and Learning here.