IST provided storage - Data protection information
Data Protection Policies at a Glance
When storage is requested, data protection is part of the discussion. Use these definitions to assist in the conversation.
Local storage snapshots for file shares (short-term recovery)
Quick rollbacks stored on the same system where your data lives. Best for "oops, I deleted that file this morning" type recoveries. Users of NFS or SMB file shares can restore files themselves without IT help. This feature applies only to file shares - not virtual machines (VMs) or block storage.
Local storage snapshots for virtual machines
These snapshots are designed for disaster recovery — they protect entire virtual machines, not individual files. If a single file loss is truly critical, recovery is possible, but it’s not the intended use as the restoration process can take days of person time. Additionally temporary storage may be required with an additional cost to the University.
SnapMirror (Disaster Recovery)
Data is mirrored between our two data centers, active/active, so if one site fails the other is available for a quick restoration of service. This is your safety net for major outages.
Note: deletes get mirrored also
SnapVault (Archive / Long-term retention)
Selected data is vaulted to a third off-site archive, where it can be kept for several months up to one year. This protects against accidental deletion discovered much later or meets compliance/regulatory needs.
Veeam Backup Service
For protection beyond snapshots or mirroring, this service offers full-system and application-aware backups, allows recovery of entire or individual files. Additional costs might apply due to separate backup infrastructure and storage.
Important notes on costs: Each layer of protection consumes additional storage space, which adds to the University’s total storage cost. Our team will discuss with you the level of protection your data requires.
Storage allocation matrix
Type | Description |
|---|---|
Single Data Centre Only | This storage tier has limited redundancy, hardware and drives are redundant, but there are no additional copies of data stored elsewhere. This is best used as your own secondary copy storage location or if you have a backup of your data somewhere else. |
Redundant Data Centre Mirror Copy | This storage tier has redundancy in hardware, drives, and data copies. But note that copies are identical, if data has been deleted in the primary copy for long enough that the snapshots (or previous version copies) have aged out, it is also deleted in the redundant one. |
Offsite Vault Copy | Used when long term recovery is required for compliance or data safety. |
Local Snapshot policies
Policy name | Schedule (Hourly / 4Hourly / Daily / Weekly) | Description of the service |
|---|---|---|
default
| 6 / 0 / 2 / 2 | Baseline coverage for common office workflows; protects from accidental deletion or overwrites without burning too much space. |
default_ext
| 6 / 0 / 7 / 4 | Longer retention for critical admin/office data that gets accessed frequently but still needs a longer “oops” recovery window. |
dept_term | 14 / 0 / 14 / 17 | An even longer term retention for very critical admin/office data that is accessed frequently and needs a longer recovery window. |
one_term
| 0 / 6 / 14 / 17 | Designed for long-term recovery (entire academic term). Handles large, less frequently modified datasets where people may notice mistakes months later. |
high_churn
| 0 / 6 / 3 / 2 | High churn workloads need more frequent snapshots for short-term rollback, but don’t require months of history. (example log storage) |
extreme_churn | 0 / 0 / 3 / 0 | Datasets that have extreme changes, and only need a minimal disaster recovery. (example databases with heavy I/O and also have their own backup strategy, or for use cases requiring disaster recovery only) |
archive_quarterly | 12 / 0 / 7 / 12 | Low-change but must be retained for regulatory or operational reasons. Captures quarters of history for audit or compliance. |
none_ephemeral
| 0 / 0 / 0 / 0 | No snapshots at all. Saves capacity where the data is disposable and backups are unnecessary. |
Important:
Hourly snapshots require more storage than daily retention
Snapshot policies are standardized — custom schedules are not available
SnapMirror (Disaster Recovery policies)
These policies mirror data between our data centres keeping them in sync. Both sites are active, so if one is unavailable, the other can be configured to continue to serve data.
Policy Name | Type | Daily | Weekly | Primary Use |
|---|---|---|---|---|
MirrorAllSnapshots | async-mirror | depending on the number of daily local snapshots | depending on the number of weekly local snapshots | Mirrors all snapshots to the partner site. Used for workloads needing identical protection on both sites. |
SnapVault (Archive policies – Third Site)
For data that must be kept beyond the local retention window, SnapVault policies send daily/weekly snapshots to a third off-site archive.
Policy name | Daily | Weekly | Total keep | Primary use |
vault-14D-16W | 14 | 20
| 34 | Keeps ~4 months. Ideal for IT logs and high-churn systems where some history is needed but not a full year. |
vault-14D-32W | 14 | 32 | 46 | Keeps ~8 months. Suitable for admin data and departmental shares. e.g. VM’s |
vault-14D-52W | 14 | 56 | 70 | Keeps a full year. Used for *research data and *compliance-heavy datasets. e.g. Filesystems with long retention. |
Service catalogue feedback
If you’d like to share any feedback about this service catalogue entry, please let us know.