06-16-2017 09:28 AM
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:
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
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.