Backup and Recovery - Optimizely CMS 12

Exam Area: Area 2 – Installation, Operation & Configuration (20%)

---

1. What Needs to Be Backed Up?

An Optimizely CMS installation has three main data stores:

Key principle: The database + blob storage together contain all customer data. Application code should always be in source control — it is not "data".

---

2. SQL Server Backup Strategies

Full backup:         Complete snapshot of the entire database
Differential:        Changes since last full backup
Transaction log:     All transactions since last backup
                     → Enables point-in-time recovery

Recommended schedule (production):

Daily:   Full backup
Hourly:  Transaction log backup
Weekly:  Test restore to verify backup integrity

---

3. Azure SQL Backups (DXP)

Azure SQL Database provides automated backups by default:

Point-in-time restore (PITR):

Azure Portal → SQL Database → Restore
  → Select point in time (within retention period)
  → Restores to a new database
  → Switch connection strings to restored DB

---

4. Blob Storage Backup

Azure Blob Storage → Geo-redundant replication (GRS):
  → Primary region: data written here
  → Secondary region: asynchronously replicated copy
  → RPO: ~15 minutes

Manual snapshot/backup:

# Azure CLI — create blob snapshot
az storage blob snapshot \
  --container-name mysitemedia \
  --name hero-image.jpg \
  --account-name mystorageaccount

---

5. DXP Self-Service Backup

The Optimizely DXP portal provides self-service database download:

DXP Portal → Environments → Production → Database
  → Download backup (.bacpac format)
  → Schedule: automatic daily backups retained for 7 days

---

6. Recovery Procedure

Full recovery after data loss:

1. Restore SQL database from backup
2. Point application connection string to restored database
3. Verify blob storage is in sync with DB
   → If blobs are more recent than DB: orphaned blobs (OK, clean up later)
   → If DB is more recent than blobs: missing media (restore blobs too)
4. Restart application
5. Verify content is accessible
6. Check Change Log for any suspicious activity

---

7. Recycle Bin (Trash)

CMS has a built-in Recycle Bin for soft-deleted content:

// Content moved to trash is still in the database
// Access via Admin: /episerver/cms/admin → Manage Waste Basket

// Programmatic restore
public class TrashService
{
    private readonly IContentRepository _contentRepository;

    public TrashService(IContentRepository contentRepository)
    {
        _contentRepository = contentRepository;
    }

    public void RestoreFromTrash(ContentReference deletedRef, ContentReference destination)
    {
        _contentRepository.Move(deletedRef, destination);
    }
}

---

8. Mirroring (Content Replication)

CMS supports content mirroring between CMS instances:

Source CMS → Mirroring service → Target CMS
  → Replicates published content
  → Useful for: DR environment, regional CDN origin servers

---

9. Recovery Point Objective (RPO) and Recovery Time Objective (RTO)

---

Review Questions

1. What are the 3 data stores that need backing up in a CMS installation? (SQL Database, Blob Storage, Application Files)
2. Should application code be backed up separately from the database? (No — code should be in source control (Git); it is not operational data)
3. What does PITR stand for and what does it enable? (Point-in-time restore — restore the database to any point within the retention window)
4. Where is the CMS Recycle Bin (trash) in the Admin UI? (Admin → Manage Waste Basket)
5. What is RPO? (Recovery Point Objective — the maximum acceptable data loss expressed as time since the last backup)