...
For long term snapshots of server(s), it is better to copy the entire VMWARE server and then document it (name, purpose, date) and save it off to a storage location.
...
Disaster Recovery Plan
Database changes likely occur every second in an MES environment. It is in this area where there is a risk of data loss and RPO tolerance consideration is the most important. Snapshots aren't really an effective means of dealing with recovery from outages which involve rapidly changing transactional data unless they are constantly being taken at short intervals. This is often not practical due to the potential negative impact on the production server of additional load and storage limitations at sites to manage and store all the snapshots.
This traditional backup-and-restore scenario is more suited for databases with lots of real-time transactional data. This can be accomplished by the effective use and planning of Full, Differential, and Transaction Log Backups. One of the main considerations in the strategic deployment of these strategies is the RTO (Recovery Time Objective). A strategy utilizing only a Full Backup and Transaction logs will have a longer RTO than a strategy utilizing a Full Backup followed by Differential backups and transaction logs.
...
| Anchor | ||||
|---|---|---|---|---|
|
A full copy of the VMWare server.
Servers | Schedule | Retention |
Application | Once every two weeks | One month |
Visualization | Once every two weeks | One month |
Process Historian | Once every two weeks | One month |
SQL Server | Once every two weeks | One month |
OPC | Once a month | One month |
Snapshots
Servers | Schedule | Retention |
Application | Every day | 2 days |
Visualization | Every day | 2 days |
Process Historian | Every day | 2 days |
SQL Server | Every day | 2 days |
OPC | Every day | 2 days |
...
In the scenarios above the time that it takes to process the recovery of each transaction log is the main factor in the RTO calculation.
The full backup, differential backup, and transaction logs have to be from the same "set". A previous full backup would not work.
Regarding data loss and MES data specifically, most transactions that come as a result of process historian data can be "re-triggered" and reprocessed very easily to the same point in time of the disaster. The transactions that are at risk to be missed are any transactions that were manually entered by operators or downloaded from 3rd party applications via interfaces.
| Anchor | ||||
|---|---|---|---|---|
|
An SQLAgent job can be set up to perform Maintenance jobs to perform Database and transaction log backups.
For example, you might schedule three jobs: Full Backup, once per day, a Differential, every 12 hours, and Transaction Log backup every 15 minutes or half-hour. Database and Transaction Log backups would then be sent to an offline storage device like a NAS server.
...
Historian Archives and OPC Project Configuration Files
Server | Backup Type | Schedule | Retention |
Historian (Off Site Backup) | |||
Full (all archives) | Once | Permanent | |
Latest 3 archives | Daily | Keep one copy of each | |
OPC Servers (Off Site Backup) | |||
Last "project" file (.opf)) | Weekly or on ad-hoc change. | Keep last two current ones |
...