School software should keep each school's data isolated, take regular backups stored away from the application servers and test them by restoring, encrypt all traffic, and limit and log who can see or change each record.
What does protecting student data actually involve?
A school system holds admission records, family phone numbers, fee payments, marks, attendance and staff salaries. Protecting that data means two separate jobs: making sure it can be recovered if something goes wrong, and making sure only the right people can see or change it.
Backups answer the first question: server failure, accidental deletion or a bad update. Isolation, access control, login security and activity logs answer the second. A system that does only one of these is not protecting the data properly.
How should school data backups be designed?
In general, a backup that sits on the same server as the live system is not much of a backup, because one failure can take both. Good practice is to copy the database regularly to separate storage, keep several older copies so a problem noticed late can still be undone, and test the copies by actually restoring them.
EDUBase keeps regular database backups off the application servers, and these backups are periodically tested by restore. Hosting, backups and monitoring are run by the EDUBase team, so the school does not manage servers itself.
- Store backups away from the live application server
- Keep more than one generation of backups
- Test backups by restoring them, not just by checking that a file exists
- Make one party clearly responsible for running and checking backups
Why does keeping each school's data separate matter?
Many cloud systems put every customer into one shared database and separate them with a school ID on each row. That works, but a single coding mistake or a mis-written report can show one school's records to another. A database per school puts a harder boundary in place: each school's records live in their own database, with their own credentials.
In EDUBase every school has its own separate database, so records are never mixed with another school's. Per-school database credentials mean no cross-school access is possible by design. Separate databases also make it simpler to back up, restore or move one school without touching the others.
Who should be able to see and change student records?
Most data problems in schools come from inside the office: a fee changed without approval, a discount nobody remembers giving, or a record deleted by mistake. Good software limits each person to the screens and actions their job needs and keeps a record of every change.
In EDUBase, staff get per-user, per-screen and per-action rights, including view-only versus edit, and a user sees only the campuses granted to them. The User Logging page records who created, changed or deleted a record, with critical, important or normal severity and a link that opens the record with the change highlighted. A daily summary of important changes reaches the navbar bell and the Owner App.
- Payments, discounts, salary changes, admissions and leave can require a second person's approval
- In the new finance ledger, a posted entry is never edited or deleted; it is reversed, with both entries kept
- Clearing demo or test data requires strict rights and the action is logged
How should logins, apps and devices be secured?
Shared passwords, logins that never expire and attendance devices using a staff member's account are common weak points. Each person and each device should have its own credential that can be cut off on its own.
EDUBase staff sign in with the school's institute code, then their username, email or mobile number and their password, and a web session ends after a period without activity. Parents log in with a one-time code sent by SMS to a mobile number saved on their child's record, so there is no parent password to manage. Attendance tablets, sender phones and gates hold their own revocable tokens, so a lost tablet can be cut off without changing anyone's password. Portal, app and integration traffic runs over HTTPS, and hosting sits behind Cloudflare.
What should monitoring and recovery look like?
Backups only help if someone notices a problem quickly. External monitoring checks the system from outside, the way a parent or teacher would reach it, and raises an alert when something stops responding.
EDUBase runs external monitoring of the servers, the resolver and the messaging gateway, with alerts to its on-call team, plus application-level checks for queues and schedulers. When comparing any provider, ask who is alerted, who restores data, and when a restore was last tested.
What should the school itself still do?
Even on managed hosting, the school controls who has access. Remove or restrict logins when staff leave, review privileges at the start of each session, and read the activity log when figures look wrong.
Every EDUBase fee report can be exported to Excel or CSV, so the office can keep its own copies of key reports, such as year-end fee audit exports, under its own retention policy.
Common approaches to backing up and separating school data
| Approach | What it involves | Main risk |
|---|---|---|
| Backups on the same server | Database copies saved alongside the live system | One disk or server failure can destroy both the data and the backup |
| Off-server backups | Copies stored on separate storage from the application server | Copies may be unusable if nobody tests them |
| Off-server backups with restore tests | Copies kept separately and periodically restored to prove they work | Needs clear ownership and regular effort from the hosting team |
| Manual copies on an office PC | A clerk exports files or copies a desktop database to a USB drive | Depends on one person remembering; drives get lost or overwritten |
| Shared multi-tenant schema | All schools in one database, separated by a school ID on each row | A query or coding mistake can expose one school's data to another |
| Database per school | Each school has its own database and credentials | More databases to run and monitor, so automation matters |
Related
- Cloud & Infrastructure Services — Managed hosting, one database per school, backups, monitoring and secure networking for education workloads.
- Data Migration & Onboarding — Students, families, fee plans, old dues, past payments and staff moved from Excel or any system, verified before go-live.
- Legacy System Transformation — Move from Excel registers, desktop software or an old portal to a modern cloud platform without losing history.
- Hosting security on edubaseems.com
- Users privileges security on edubaseems.com
- Finance accounting on edubaseems.com
- Face attendance on edubaseems.com
- Qr biometric attendance on edubaseems.com
- Bulk data import on edubaseems.com