BookmarkSubscribeRSS Feed
SAS Employee

Hi all,


backup and restore is a very important topic!


Working with customers, I saw many cases where either no backups or, only monthly backups

were taken, not considering the SAS environment and SAS backup at all. Consequently, when

restores became necessary, the backup did not include all SAS data, and with that, data was lost.

Often weeks' or months' worth of data.


To make sure you do have a proper backup strategy in place, the following provides you with

some information and best practices.


Backing up your SAS environment


As a starter, the following provides you with material, covering everything you need to know about

taking proper backups:


About Backup and Restores


Best Practices for Backing Up your SAS Content


Best Practices for Restoring your SAS Content


Some Background:

It is important that the system backup or third party backup you are using includes SAS:

content, metadata, config files. Basically, everything you'll find underneath your

SAS config dir, and the Content Server, all config files.

SAS related data stored outside of the SAS config will not be backed up by the SAS backup!!


Why it is so important:

The Metadata Server that stores all your metadata (users, groups, libraries, tables, web content,

folders etc.) is an in-memory server. When users request metadata, a copy of the physical table

is created and "put" into memory. It remains in memory until the metadata server is paused and

resumed, or stopped and restarted. The pausing and or stopping flushes the content that

is held in mem, to disk. This is key!!

If you only run a sys backup without considering SAS, all data on disk is backed up,

however, what is kept in memory will not be part of the backup.


Think of it as a puzzle: you have a complete puzzle, and then you take some puzzle

pieces out and throw them away. You will never be able to put the puzzle back together.

Same concept with the metadata server.

If you backup without considering SAS, whatever is kept in memory will not be part of the

backup. If a restore would become necessary, it would be incomplete, and with that, not

usable. Data would be lost.


The SAS backup facility (the different options are described in the doc mentioned above) runs an

automatic backup each night at 1pm. The SAS backup pauses the metadata server automatically,

runs the backup, and then resumes the metadata server. The pause flushes the content that

is kept mem to disk.


You can change the time, define the folder where the SAS backup is to be stored, if you do not want

to use the default SAS put in place. The ways to change the default settings is described in the

doc mentioned.


In addition to the backup, SAS runs a reorg once a week. The reorg will reclaim unused disk space

that might be "left over" when metadata has been deleted.

As a best practice, it is recommended to keep the default at ones a week.


If you are running jobs at night, or, if you do run a backup during the day and users run jobs,

already submitted jobs are put on hold until the backup ran, then continue.

New jobs that are submitted are being "refused" until the backup finishes.

A SAS backup usually doesn't run very long. Of course, this depends on the amount/size of your

metadata, but generally, it would not affect any work too much.

To use another analogy to explain users running jobs during a backup, the process of jobs being put

on hold or being "refused" during a SAS backup is like a phone call.

If you talk to someone and then put the person on hold, (s)he is still on, yet paused.

If a third person now tries to call you, its busy, and the call cannot be accepted. However, ones you

end the phone call, you can then be reached again. Same concept.


Talk to your sys admins (or whoever is responsible for backups in your company) and

make sure that the SAS backup/SAS environment is part of the system backup!


To summarize the above:

It is of the utmost important to have a proper SAS backup in place to make sure you can restore

successfully if it would ever become necessary.


Having seen many cases where data was lost, I cannot stress this enough.


Whenever you install a hot fix, a maintenance release, and whenever you make any changes to

your environment (significant changes), you can run an ad-hoc backup. Please take a look

at SAS Backup Facility. It is strongly recommended to run ad-hoc backups whenever you make any

changes to your environment.


This article is meant to provide you with a high-level overview of SAS backups. Depending on

your environment (Grid to name one example), backups might require different strategies.

The documentation provided will gives you the tools and knowledge needed for making sure

a proper and successful backup strategy is in place. 


Please let me know if you have any questions.





suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

Get Started with SAS Information Catalog in SAS Viya

SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 0 replies
  • 1 in conversation