← Back to NIKSHA OS

NIKSHA OS — Data Backup & Recovery Policy

Version 2.0 · Last updated 7 October 2026

Operator: NIKSHA Technologies ("NIKSHA OS", "we", "us").

This policy explains how NIKSHA OS protects against data loss through backups, and how it restores service after an incident. It supports the Security Policy and the Privacy Policy.

1. Goal

Protect schools' data against accidental loss, corruption, or hardware/software failure, and be able to restore the service to a recent, consistent state.

2. What we back up

• The production database (all school operational data: students, attendance, exams, fees, communication, audit logs, legal-acceptance records, etc.).
• Uploaded files (photos, documents) are held in Cloudflare R2 object storage. Critical document areas are designed to be copied, encrypted, to the off-site backup bucket; because that bucket is not yet switched on (§4), uploaded files currently rely on R2's own durability. Bulk media (for example School Memories) is excluded from file backups by design.
• Configuration needed to rebuild the service.

3. How backups work

• Schedule: automated nightly backups of the production database.
• Encryption: backups are encrypted at rest.
• Integrity: a backup that cannot be restored is not a backup, and we treat restore testing as the only real proof. We do not currently claim a passing restore test. An earlier version of this document asserted that backups are "restore-tested"; that claim has been withdrawn because project records note a restore drill that did not pass. Restore verification is open work, and this line will be updated when a drill passes — not before.
• Health monitoring: a backup-health signal is exposed to operations monitoring, and alerts fire if a backup is missed or fails.
• Retention: backups are kept on a rolling cycle; older backups age out and are deleted, which is also how deleted records eventually disappear from backups (see the Retention Policy).

4. Where backups are stored

Corrected 8 August 2026. An earlier version of this section said the production service is "self-hosted (not on a third-party managed cloud database)". That is no longer true.

The production database is Supabase Cloud, hosted in India (Mumbai, ap-south-1), since 8 August 2026. Our previous self-managed database is retained in read-only form as a rollback. Application and API servers run on a virtual server the operator manages, rented from Hostinger, located in India (Mumbai).

Backups are stored within the operator's controlled infrastructure. An off-site backup destination exists in the design but is not currently configured, so no backup data is presently leaving that infrastructure. See Sub-processors §2 and §4.

5. Recovery objectives (targets)

These are operational targets, not guarantees, and will be tightened as the service matures:

6. Restore process

1. Confirm the incident and decide the recovery point.
2. Provision/clean the target environment.
3. Restore the most recent verified backup (database + files).
4. Validate integrity and key journeys before reopening access.
5. Communicate status to affected Institutions.
6. Record a post-incident review and improvements.

7. Responsibilities

• NIKSHA OS maintains backups and runs recovery of the central service.
• Schools remain responsible for data they choose to export and hold outside NIKSHA OS, and for following their own continuity practices.
• Backups are subject to the same security and access controls as production data; only authorised operations personnel can access them.

8. Limits

Backups reduce, but cannot entirely eliminate, the risk of data loss. In a severe event, the most recent recoverable state may be the last successful backup. Schools should keep their own copies of records they are legally required to retain.

9. Changes

Material changes to this policy are recorded in the CHANGELOG.