1. Purpose

This policy describes how customer data is backed up, protected, retained, and made available for recovery in the event of accidental deletion, system failure, data corruption, infrastructure disruption, malicious activity, or a major disaster.

Our backup architecture uses multiple independent recovery layers rather than relying on a single server, storage device, or backup location.

This policy applies only to customers and users whose accounts and services are active at the time the applicable backup is created and maintained.*

2. AWS Infrastructure

Our primary production environment is hosted in the Amazon Web Services Mumbai Region.

AWS has been selected because it provides:

AWS Regions are designed to be isolated from one another, while each Region contains multiple separate Availability Zones. This allows systems and backups to be protected from the failure of an individual physical location.

3. Backup Storage Architecture

Customer data is protected through the following backup layers:

3.1 Local Operational Backup

Recent backups are maintained close to the production environment for rapid recovery from minor operational incidents.

The latest three local recovery points may be retained for situations such as:

  • Accidental file deletion
  • Recent database restoration
  • Failed application deployment
  • Configuration rollback
  • Small operational recovery

Local backups provide fast recovery but are not treated as the only disaster-recovery mechanism.

The estimated recovery time from an available and valid local backup is approximately 2 to 3 hours, depending on the volume of data, database size, infrastructure availability, and validation requirements.

3.2 Amazon S3 Backup

Backup files are uploaded to Amazon Simple Storage Service, commonly known as Amazon S3, in the AWS Mumbai Region.

Amazon S3 acts as the primary durable repository for daily, weekly, and monthly backups.

S3 stores objects redundantly across multiple devices and, for the storage classes used under this policy, across a minimum of three Availability Zones within an AWS Region. AWS also performs integrity checking and automatically repairs lost storage redundancy.

3.3 Infrastructure Snapshots

Scheduled infrastructure snapshots are maintained for volume-level and server-level restoration.

Snapshots may be used to recover:

  • Application server volumes
  • Database storage volumes
  • Operating-system configurations
  • Application configuration
  • Infrastructure affected by storage or deployment failure

4. Backup Schedule and Retention

Backup Type Frequency Retention Primary Storage
Local operational backup Daily Latest 3 recovery points Production environment
Daily S3 backup Daily 14 days Amazon S3, Mumbai
Weekly S3 backup Weekly 28 days Amazon S3, Mumbai
Monthly archival backup Monthly Indefinite* Amazon S3 archival storage
Infrastructure snapshot Scheduled Defined operational recovery points* AWS snapshot storage

The architecture therefore provides daily, weekly, monthly, local, archival, and snapshot-based recovery options.

5. How Amazon S3 Backup Works

When a scheduled backup is completed, the backup file is securely uploaded to a restricted Amazon S3 bucket.

The backup is classified as daily, weekly, or monthly. Automated S3 Lifecycle rules then apply the appropriate retention period and storage class.

5.1 Daily Backups

Daily backups are retained for 14 days and are then automatically removed after completion of the approved retention period.

These backups support recent operational recovery and rollback.

Where the backup remains available in an immediately accessible S3 storage class, the estimated end-to-end recovery time is approximately 6 to 8 hours.

5.2 Weekly Backups

Weekly backups are retained for 28 days and are then automatically removed after completion of the approved retention period.

These backups provide recovery points for issues that may not be detected immediately.

Where the backup remains available in an immediately accessible S3 storage class, the estimated end-to-end recovery time is approximately 6 to 8 hours.

5.3 Monthly Backups

Monthly backups are retained indefinitely and do not have an automatic deletion rule, subject to the account remaining active and the conditions stated in this policy.*

To control long-term storage costs, monthly backups progressively move through AWS storage classes:

  • Initially stored in S3 Standard
  • After 30 days, moved to S3 Standard-Infrequent Access
  • After 90 days, moved to S3 Glacier Instant Retrieval
  • After 365 days, moved to S3 Glacier Deep Archive

The backup remains retained while being moved to storage designed for less frequent access.

Estimated recovery times are as follows:

Backup Storage Source Estimated Recovery Time
Local operational backup Approximately 2 to 3 hours
S3 Standard or Standard-Infrequent Access Approximately 6 to 8 hours
S3 Glacier storage Approximately 12 hours
S3 Glacier Deep Archive Approximately 3 to 5 working days

Backups stored in archival storage require an archive-retrieval process before restoration can begin. Recovery time includes retrieval initiation, file availability, data transfer, database restoration, application-level validation, and service-readiness checks.

6. Backup Security

Backup repositories are protected through security controls that may include:

Amazon S3 Versioning allows previous versions of an object to be retained, helping recovery where a backup object is accidentally overwritten or deleted.

S3 Object Lock may be applied to critical recovery points to prevent protected backup versions from being deleted or changed during their defined retention period.

Amazon S3 provides server-side encryption for stored objects, and access to backup data remains controlled through authorised AWS identities and permissions.

Backup buckets are not made publicly accessible.

7. Disaster Recovery

Different recovery sources are available depending on the nature of the incident:

The recovery source is selected based on the incident type, required recovery point, backup availability, data volume, storage class, system dependencies, and required validation activities.

The estimated recovery periods stated in this policy are planning estimates and not guaranteed service-restoration commitments. Actual recovery time may vary depending on:

8. Monitoring and Validation

Backup jobs are monitored for:

Backup completion alone is not considered sufficient proof of recoverability. Periodic restoration testing is performed to confirm that selected backups can be restored and validated at the database and application level.

9. Policy Summary

Our backup policy uses a layered AWS architecture consisting of:

This approach reduces dependency on any single server, storage system, or Availability Zone and provides multiple recovery options for operational incidents, data corruption, infrastructure failure, accidental deletion, malicious deletion, and other disruptive events.

Important Note

* This Backup and Data Protection Policy applies only to active users and active customer accounts. Backup creation, retention, archival storage, restoration availability, and indefinite monthly retention are applicable only while the customer’s account, subscription, or service relationship remains active. Data belonging to inactive, suspended, terminated, expired, or closed accounts may be deleted in accordance with the applicable agreement, data-retention terms, legal requirements, and internal data-disposal procedures.

The recovery times stated in this policy are approximate estimates and begin after the recovery request has been authorised, the relevant backup has been identified, and the required recovery infrastructure and personnel are available.