As my colleague @RobCollum wrote in his post on communities.sas.com the combination of CI/CD and DevOps has led to a whole new world how software today is built, packaged and delivered. Since Viya 2020 SAS is releasing software that way. More specifically SAS Viya has two release cadences: Stable or Long-Term Support cadence. Especially with the Stable cadence the updates come quickly: at least once a month and probably more when patches are released. While it’s nice to have continuous updates to the SAS software, production environments where users are actively creating content are often protected from frequent, ad-hoc changes.
That’s why I like the idea of a Blue/Green Deployment. I can make use of the backup/restore functionalities in SAS Viya to first create an identical box as my source environment. Working this way we can say it's a Viya 4 to Viya 4 Full System migration. But make sure you use the same Ingress Hostname. After restoring the backup content I can safely apply the update on the new target environment. If tests can confirm that everything is still working and all my Data, SAS Models, SAS VA reports, .. are still available I can execute the Blue/Green switch by changing the DNS entry of my Ingress Hostname to a new LoadBalancer IP address.
In this blog I wanted to share a video how I run the first part. So how I restore a backup on a fresh Viya environment. For the the update process I refer to the Viya Operation guide. How to do the Blue/Green switch I will post in a follow up of this article but don't hesitate to drop me an email if you want to learn more about it. Let me start with introducing the flow that you will see in this video.
I will start with checking if a scheduled or ad-hoc backup completed successfully. With the following kubectl get jobs command I can retrieve all backup jobs. (please note I’m using the alias k for kubectl)
k get jobs.batch -n hackinsas-eugtp -l "sas.com/backup-job-type=scheduled-backup" -L "sas.com/sas-backup-id,sas.com/backup-job-type,sas.com/sas-backup-job-status,sas.com/sas-backup-persistence-status"
We will need the SAS-BACKUP-ID later when we do the restore of the content.
If you want to restore the backup content to a new target environment you will need to access the physical location of your Kubernetes Persistent volumes of the current Viya environment. In my case the persistent volumes are provisioned via a NFSServer that I can access via a jumpbox. On that jumpbox I create two zip files (BACKUP_ID_cas.zip and BACKUP_ID_common.zip ) containing all the files I need to restore a backup.
The BACKUP_ID_cas.zip and BACKUP_ID_common.zip needs to be migrated to the similar Persistent Volumes of the target environment. There you can unzip the files so that you have the backup available on the target environment. Don’t forget to allow sufficient permissions to the extracted folders.
Once your BACKUP is on the target Persistent Volumes you can start following the ‘Perform a Restore’ like described here in the SAS Viya Operations guide. (Make sure your select the guide for your release and cadence).
Watch the following video demonstrating backup and restore of SAS Viya content.
Big thanks to @RobCollum @GerryNelson @RPoumarede for their feedback and help in creating this article.
Also have a look to this articles from my colleague @GerryNelson:
Registration is now open for SAS Innovate 2025 , our biggest and most exciting global event of the year! Join us in Orlando, FL, May 6-9.
Sign up by Dec. 31 to get the 2024 rate of just $495.
Register now!
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.