Backup, uptime and recovery for a school ERP

Imagine it is the last day of the fee window, a Monday morning with hundreds of parents paying online, and the system slows to a crawl. Or a result-publication day when every family logs in at the same moment. Or a server fault that corrupts a week of records.

These are not exotic scenarios. They are the moments when an ERP either proves its worth or exposes its weaknesses. Reliability is rarely a headline feature on a vendor's page, but it is one of the most important things to evaluate.

• Uptime: the percentage of time the system is available. A promise of 99.5 percent leaves room for a few hours of downtime per month, while 99.9 percent allows well under an hour. The number matters less than how it is measured and what happens when it is missed.
• Backup: a copy of your data stored separately so it can be restored after loss or corruption.
• RPO (Recovery Point Objective): how much recent data you can afford to lose. If backups run every 24 hours, you could lose up to a day's entries. If they run more frequently, or continuously, the potential loss is smaller.
• RTO (Recovery Time Objective): how long it takes to get back to working order after a serious failure.

You do not need to be technical to ask about these, and a good vendor will answer plainly.

1. How often is data backed up, and what is the retention period?
2. Where are backups stored? They should be separate from the primary system, ideally in a different location.
3. Are backups encrypted?
4. When did you last test a restore? Backups that have never been restored are hopes, not safeguards.
5. Can you restore a single school's or branch's data without affecting others?
6. Can we request our own export of our data on a regular basis? Keeping an independent copy under your control is a sensible extra layer.

1. What uptime do you commit to in writing, and how is it measured?
2. What are the remedies if you fall below it?
3. When do you perform maintenance? Planned work should fall outside school hours and be announced in advance.
4. How does the system behave under peak load? Ask specifically about fee due dates, admission openings and result days, and whether the platform has been tested for concurrent use.
5. Is there a public or shared status page or notification process for incidents?

1. How quickly will you tell us about a problem, and through what channel?
2. What are your support hours, and what response times do you commit to for urgent issues?
3. Who is our escalation contact when something goes badly wrong?
4. Do you share a post-incident summary explaining the cause and the fix?

1. Is there a documented disaster recovery plan, and how often is it exercised?
2. What happens to our data and access if the contract ends or the company is acquired?
3. In what formats can we export our records, and at what cost?

Even excellent systems have bad days, and connectivity at the campus can fail regardless of the vendor. Prepare a simple procedure so that a disruption is an inconvenience, not a crisis:

• Attendance: keep printable class sheets ready, and enter data afterwards
• Fee counters: keep a manual receipt process for emergencies, with a rule that each manual receipt is keyed into the system within a set time
• Communication: have an alternative channel for urgent notices to parents and staff
• Roles: name who declares downtime, who informs staff and who follows up with the vendor
• Review: after any incident, note what worked and what did not

Data protection rules in India expect institutions to apply reasonable safeguards, and backups and business continuity are commonly counted among them. Being able to describe how your data is protected against loss, not only against theft, is part of showing responsible stewardship of student information.

A vendor's answers to these questions reveal a great deal. Clear, specific, documented replies suggest a team that has thought about failure. Vague reassurance suggests otherwise. Ask before you sign, and ask again at renewal.

For the security side of the picture, read what ISO 27001 and AES-256 actually mean.