Disaster recovery & BI

A word about Sveltekit adapters.

21RISK is built with Sveltekit , a modern application framework that makes a clear abstraction so developers don’t have to think about the target deployment. This makes it very flexible to change where the application code is deployed. As of june 2023, Sveltekit supports the following deployment targets:

Failover strategy

Failover strategy

To avoid any downtime we utilise a comprehensive failover strategy on all avenues of our application. This helps ensure that any regional or local incidents do not impact performance and result in downtime.

• Vercel uses AWS Global Accelerator and Anycast network to automatically reroute traffic to another region in case of regional failure.
• Edge functions and Edge Middleware switch to another region automatically using Cloudflare's automatic failover feature
• Mongodb Cross cloud failover - ensures that data is replicated to multiple regions.
• Mongodb Multi cloud provider backups - We do periodic backups to multiple different cloud providers to ensure that even in the event of a total loss of the cloud provider AWS we still have ensured our data.

Disaster Recovery Plan

Disaster Recovery Plan

A Disaster Recovery Plan (DRP) is essential for businesses of all sizes, including your small development team. The purpose of a DRP is to ensure that your team can respond to a disaster or other emergency that affects information systems and minimize the effect on the operation of the business.

Risk Assessment

Risk Assessment

An ordered list of the most critical incidents to affect our system: This list provides the foundation for the steps we take in order to minimize the impact if they should occur.

• Regional at MongoDB Atlas -> Failover strategy
• Complete Outage at MongoDB Atlas -> Move to alternate processing site
• Outage at Doppler -> Move to alternate processing site
• Outage at WorkOS -> Move to alternate processing site
• Regional outage at Vercel -> Failover strategy
• Complete outage at Vercel -> Move to alternate processing site
• Outage at AWS -> Move to alternate processing site
• Outage at Github -> Move to alternate processing site

Identify Critical Assets

Identify Critical Assets

Identify which data, hardware, and software are critical to business operations. Prioritize their recovery in the event of a disaster.

• MongoDB Atlas
• WorkOS
• UploadCare
• Github
• NPM
• Doppler
• AWS
• Power BI

Backup and Restore Procedures

Backup and Restore Procedures

Disaster Response

Disaster Response

Step 1 Better stack will automatically contact Alex and Andreas, when downtime in the system is identified.

Step 2 Depending on the severity of the plan, a physical meetup is arranged with the priority to protect/verify all backups are in place.

Recovery Procedures

Recovery Procedures

Document the steps necessary to recover each of your critical assets. This should include steps to restore data from backups, how to ensure that restored systems are secure, and how to validate that systems are functioning correctly after recovery.

Alternate Processing Sites: For critical systems

Alternate Processing Sites: For critical systems

In the event of a disaster at one of our current service providers, we would migrate the following services to the alternative providers to ensure functionality. 28 Please note that the alternate providers are not actively used currently.