SCHOOL DATA BACKUP STRATEGY

How schools' data backup, retention, and disaster recovery are handled on Smart Schoolz Hub

1. Two-Tier Backup Architecture

Smart Schoolz Hub employs a defense-in-depth, two-tier backup model:

Tier 1: Platform-Level Cloud Backups — disaster recovery and infrastructure protection.

Automated Infrastructure Backups (Lovable Cloud / AWS Engine)
- Continuous Write-Ahead Logging (WAL) for Point-in-Time Recovery (PITR)

- Daily automated full system snapshots
- Redundant AWS S3 storage across multi-availability zones in Europe
Tier 2: School-Level On-Demand Exports — data sovereignty, offline archiving, and instant portability.
- School-Level Self-Service Exports (Security & Data Module)
- On-demand, one-click offline ZIP archive
- Contains all 40 modular school tables (CSV) + schema documentation
- Kept locally by the school for offline archiving and compliance

2. Backup Specifications & Parameters

Parameter	Platform Infrastructure Backups (Tier 1)	School Self-Service Backups (Tier 2)
Backup Frequency	Continuous WAL streaming (every transaction) + daily full snapshot, run automatically during low-traffic off-peak hours.	On-demand and unlimited. Schools can generate backups at any time. Weekly or term-milestone backups are recommended.
Retention Period	7–30 days rolling recovery window for daily snapshots, allowing point-in-time state restoration.	Permanent and school-controlled. Once downloaded by the school, retention is managed according to the school's internal record-keeping policy.
Storage Location	AWS Europe (`eu-north-1`) secure S3 vaults. Encrypted at rest (AES-256) and physically isolated from live compute instances.	Local school storage, external drive, or the school's Google Drive/OneDrive.
Encryption & Access	Encrypted in transit (TLS 1.3) and at rest (AES-256). Accessible strictly by automated infrastructure pipelines, with zero public access.	Generated through an authenticated School Admin session, verified through strict role checks and logged in the Activity Log.

3. Recovery Provisions in Case of Data Loss or Workspace Compromise

Scenario A: Accidental Bulk Deletion or Data Corruption

Point-in-Time Recovery (PITR)

Because database transactions are continuously written to write-ahead logs, the backend can roll back the database state to the appropriate point before an accidental corruption or destructive action.

School CSV Restoration

School Administrators can use their downloaded CSV archives alongside the platform's bulk import tools, such as student imports and class allocations, to repopulate cleared records without losing historical data.

Scenario B: Compromised Workspace or Stolen Staff Credentials

1. Immediate Workspace Quarantine (Emergency Pause)

Platform Admins have an emergency toggle in the Platform Admin panel to pause a workspace instantly.
Pausing immediately halts write operations, blocks session access, and freezes the tenant so a rogue actor cannot alter records while the incident is investigated.

2. Session Revocation & Credential Reset

School Admins or Platform Admins can revoke access for the compromised account.
Passwords can be regenerated, and staff roles can be downgraded to `inactive`.

3. Forensic Audit Trail

The immutable Activity Log records relevant activities, including logins, score updates, fee collections, and record modifications, with timestamps and user identifiers.
This enables administrators to determine which records and activities were affected during a compromise.

4. Tenant Isolation Guarantee

Tenant data is logically isolated through PostgreSQL Row-Level Security (RLS).
A compromise within School A cannot traverse or expose School B's records, subject to the correct implementation and configuration of the platform's access-control policies.

4. CLEAR RECOVERY RESPONSIBILITY MATRIX

Recovery responsibilities are shared between Smart Schoolz Hub Platform Administration and the School Administration.

This ensures that every party understands what it is responsible for before, during, and after a data-loss or security incident.

Recovery Area	Smart Schoolz Hub Platform Responsibility	School Responsibility
Platform Infrastructure Failure	Maintain automated infrastructure backups, WAL/PITR capabilities, database recovery processes, and cloud infrastructure resilience.	Report the incident promptly and provide information required to identify the affected workspace and timeframe.
Accidental Data Deletion	Investigate the incident and use available platform-level recovery mechanisms where applicable.	Report affected records, approximate deletion time, and users/actions involved as soon as possible.
Bulk Data Corruption	Assess the scope of corruption and initiate appropriate database recovery procedures using available backups and recovery logs.	Stop further changes where instructed and provide relevant information about when the corruption was detected.
School Export Recovery	Provide export functionality and supported bulk-import tools.	Maintain downloaded exports securely and use them for restoration where appropriate.
Lost or Stolen Staff Credentials	Support account/session revocation and platform-level security controls where applicable.	Immediately report suspected compromise, reset affected credentials, and review/restrict affected staff access.
Compromised Workspace	Quarantine/pause the affected workspace where required, investigate platform activity, and support recovery.	Notify the platform team immediately, identify potentially compromised accounts, and cooperate with the investigation.
Activity/Audit Investigation	Maintain and provide relevant platform audit information according to applicable access policies.	Review school-level Activity Logs and identify suspicious users, transactions, or record changes.
Tenant Isolation	Maintain PostgreSQL RLS, tenant isolation, and access-control mechanisms.	Ensure staff are assigned only the roles and permissions required for their duties.
School-Level Backup Retention	Provide tools for schools to generate and download their data exports.	Download, securely store, protect, and retain school exports according to the school's record-keeping requirements.
Restoration from School Export	Maintain supported import mechanisms and provide reasonable technical guidance on their use.	Provide appropriate backup files and authorize/perform restoration of school records.
Post-Incident Verification	Confirm platform infrastructure and recovery processes are functioning following a platform-level incident.	Verify restored student, staff, academic, financial, and administrative records before resuming normal operations.
Recovery Testing	Maintain and test platform-level backup and recovery mechanisms as part of infrastructure operations.	Periodically test school-held exports to ensure they are accessible, complete, and usable for restoration.
Final Recovery Sign-Off	Confirm completion of platform-level technical recovery where applicable.	Confirm that school operational data has been reviewed and that the school is satisfied with the restored records.

Recovery Responsibility Principle

Smart Schoolz Hub is responsible for platform-level infrastructure resilience, automated backups, technical recovery mechanisms, tenant isolation, and platform security controls.

The School is responsible for maintaining its own downloaded exports, protecting school credentials, controlling staff access, reporting incidents promptly, and verifying school-level data following recovery.

5. Recommended School Operational Best Practice

1. Weekly Export

Download a full export from: Security & Data Protection Module → Export School Data. Recommended: at the close of business every Friday.

2. Term-End Seal

Generate and securely archive a complete export before finalizing report cards, promotions, and other major end-of-term processes.

3. Restricted Admin Access

Keep School Admin credentials restricted to the Proprietor/Principal. Use specific roles for operational staff, such as: Teacher; Bursar; Front Desk; Other appropriately scoped staff roles.

4. Secure Offline Storage

Maintain at least one copy of important school exports in a secure location separate from the primary computer used to access Smart Schoolz Hub.

5. Periodic Recovery Testing

Schools should periodically verify that exported files can be accessed and restored using the available import tools.

6. Our Approach to School Data Protection

Smart Schoolz Hub is designed around three important principles:

BACKUP — Protect school data against accidental loss, corruption, and infrastructure failure.

PORTABILITY — Give schools the ability to export and retain their own data.

RECOVERY — Provide mechanisms for restoring operations following data loss or a security incident.

The combination of automated infrastructure-level protection and school-controlled exports provides schools with multiple layers of protection rather than relying on a single backup mechanism.

Important Recovery Limitation

Platform-level backups are primarily intended for disaster recovery and infrastructure incidents. They should not be treated as a substitute for the school's own data exports.

Schools should therefore maintain regular independent exports, particularly before major events such as:

End-of-term report-card processing
Student promotion or graduation
Major fee reconciliation
Bulk data imports or updates
Changes to school administration
Any significant migration or operational change

This shared-responsibility model ensures that recovery does not depend entirely on either the platform or the school and provides multiple layers of protection for critical school records.