Disaster Recovery

AccessPoint runs entirely in your Azure subscription. Disaster recovery planning leverages Azure's built-in redundancy and recovery capabilities. The publisher does not hold any customer data, so recovery is fully within your control.

Recovery Objectives

Backup and Recovery

Database

• Point-in-time restore (PITR): Automatic, up to 35 days. No manual configuration required.
• Long-term retention (LTR): Configure weekly, monthly, or yearly backups for compliance. Set up via Azure Portal > SQL Database > Backups > Retention policies.
• Geo-redundant backup: Enabled by default on Standard and Premium tiers. Allows restore to a paired Azure region in case of a regional outage.

Blob Storage

• Soft delete: Enable soft delete for blobs and containers to recover accidentally deleted documents. Recommended retention: 30 days.
• Versioning: Enable blob versioning to maintain previous versions of overwritten documents.

Configuration

Export or document your configuration packs before making major changes. If a configuration change needs to be reverted, the only option is to restore from a database backup.

Rollback Procedures

API Rollback

The API is deployed as a zip package to Azure App Service. To revert to a previous deployment:

1. Open the Azure Portal and navigate to your App Service
2. Go to Deployment Center > Deployment history
3. Locate the previous successful deployment
4. Select it and click Redeploy
5. Verify the application is functioning correctly

If you use deployment slots, swap back to the previous slot via Deployment slots > Swap.

Database Rollback

DacPac deployments are additive by default — new columns and tables are added but existing objects are not removed. This provides a safety net for most schema changes.

For data issues (corrupted or incorrect data), use Azure SQL point-in-time restore:

1. Restore the database to a moment before the issue occurred
2. Verify the restored database contents
3. Update the App Service connection string to point to the restored database, or rename the databases to swap them

SPFx Rollback

To revert the SPFx web part to a previous version:

1. Download the previous version's .sppkg package from the Realizer portal
2. Open the SharePoint App Catalog
3. Upload the previous package, replacing the current version
4. Click Deploy

Configuration Rollback

Configuration packs are additive — importing a pack adds or updates items but does not remove existing ones. To revert configuration changes, restore the database from a point-in-time backup taken before the change.

Disaster Recovery Scenarios

Scenario 1: Accidental Data Deletion

1. Documents deleted from Blob Storage: If soft delete is enabled, recover blobs within the configured retention window
2. Database records deleted: Use Azure SQL point-in-time restore to the moment before the deletion. Copy the needed records from the restored database to production.

Scenario 2: Azure Region Outage

If the Azure region hosting your deployment becomes unavailable:

1. Azure SQL: Restore from geo-redundant backups to a new SQL Server in a different region
2. Blob Storage: If using geo-redundant storage (GRS or RA-GRS), initiate an account failover. If using locally redundant storage (LRS), data must be restored from an external backup.
3. App Service: Redeploy using the Bicep template in the recovery region
4. DNS and API URL: Update the AccessPoint API URL storage entity in SharePoint to point to the new App Service URL

Scenario 3: Full Environment Rebuild

The entire AccessPoint environment can be rebuilt from scratch using the published deployment artifacts:

1. Run the Bicep template to provision all Azure resources
2. Deploy the API zip to the App Service (included in ARM deployment)
3. The database schema auto-deploys on first API startup
4. Upload the SPFx .sppkg to the SharePoint App Catalog
5. Run Deploy-AccessPoint.ps1 to configure Entra-only SQL auth and Graph permissions
6. Restore the database from the most recent backup to recover data
7. Restore Blob Storage documents from geo-redundant backups

Infrastructure as Code (Bicep templates) and the deployment script ensure the environment is fully reproducible.

Planning Recommendations

• Enable geo-redundant storage (GRS) on the Blob Storage account for cross-region document redundancy
• Enable long-term retention (LTR) on Azure SQL for weekly, monthly, and yearly backups beyond the default PITR window
• Enable soft delete on Blob Storage with a 30-day retention period
• Enable blob versioning to recover overwritten documents
• Document your deployment parameters — keep a record of your tenant name, resource group, alert email, and any custom App Service settings so you can redeploy quickly
• Test recovery annually — restore the database and Blob Storage to a test environment to verify your backups are working
• Consider Azure Front Door or Traffic Manager if your organization requires automatic failover with minimal downtime

Health Monitoring

AccessPoint exposes two health check endpoints:

Key Metrics to Watch

Scaling

Vertical Scaling (Scale Up)

Change the App Service plan tier in Azure Portal > App Service > Scale up (App Service plan). No redeployment required.

Horizontal Scaling (Scale Out)

The AccessPoint API is stateless and supports multiple instances. Configure manual or automatic scaling in Azure Portal > App Service > Scale out (App Service plan).

SQL Scaling

Adjust the database tier based on workload. Common service objectives: Basic, S0, S1, S2, S3, P1, P2.

Certificate and Secret Rotation