Student websites should be backed up — by the platform, as part of the service, because a policy of 'students back up their own coursework' is a policy of losing coursework — with students able to restore their own files and databases where the panel supports it, lecturers able to reset teaching accounts to a known state, and assessed submissions preserved separately from live sites at the moment of submission. The distinctions that keep this coherent: a backup is a copy you restore from, a snapshot is a point-in-time image, a reset is a deliberate return to a starting state — and an assessment archive is none of these, but its own discipline with its own retention clock.
Should student websites be backed up at all?
Yes, and treating the question as open is how coursework gets lost. Student sites concentrate exactly the risk factors that make backups earn their keep — inexperienced operators, experimental changes, deadline-driven work on dynamic applications — and the cost of loss is not a business's revenue but a student's assessed work, which is worse in every way that matters to a university. An estate-level backup regime is cheap relative to one appeals case built on 'the platform lost my project'.
The honest counterpart: backups are a safety net, not a filing system. They protect against loss; they do not organise, version or preserve work for assessment — those are Git's job and the archive's job respectively, and conflating them is the root of most recovery disappointments.
Who is responsible for backups — platform, institution or student?
Split it in writing, because unstated assumptions here fail at the worst moment. The workable division: the platform backs up the estate — accounts, files, databases — on a regular cycle, as part of the managed service (on Education Host student hosting, monitoring and backups are part of the service; the specific cycle and retention for a deployment are confirmed during scoping rather than promised generically). The institution owns policy: what the assessment archive keeps, for how long, and what students are told. The student owns their working copies — code in version control, exports of their own site before risky changes — as professional habit, not as the estate's safety net.
The line to give students is the honest one: 'the platform can usually save you; behave as if it cannot'. That produces graduates with backup habits and an estate where restores are rare enough to be fast.
What is the difference between a backup, a snapshot and a reset?
Three operations, regularly confused, worth one clean paragraph each. A backup is a stored copy of data (files, a database) taken on a schedule, from which you restore what was lost — granular, and the everyday recovery tool. A snapshot is a point-in-time image of a whole thing (an account, a server volume), fast to take and fast to roll back wholesale — the platform's tool more than the student's. A reset is deliberate: returning an account or application to a defined starting state — not recovery from loss but a fresh start, which is why it belongs to teaching workflow (new exercise, new term, unsalvageable WordPress) rather than to disaster response.
The distinction matters practically because they answer different requests: 'I deleted my CSS folder' wants a backup restore; 'everything since Tuesday is wrong' might want a rollback; 'give me a clean site' wants a reset. Support that asks which of the three the student means resolves tickets in one exchange.
Can students restore their own files and databases?
Where the panel supports it, yes — and self-service restore is worth prioritising in any evaluation, because it converts the commonest recovery events (deleted files, a broken database after a botched import) from support tickets into two-minute student operations. In cPanel-based estates, students typically can restore files or database contents from the available backup points themselves, with the panel showing what points exist.
Database restores deserve their specific mention in teaching materials because dynamic coursework lives there: a WordPress site's content is its database, and a student who restores files while leaving a corrupted database has recovered the wrapping paper. Teach the pairing — files and database restored together to the same point — and the export habit before risky operations (a one-click database export before 'trying something' is the cheapest insurance in web coursework).
How do lecturer resets work for teaching?
As a teaching operation with guard rails: a lecturer (or the platform on their behalf) returns a student's account or application to a defined state — the module's starter site, or empty — because the exercise demands a fresh start or the site is beyond sensible repair. It is the hosting sibling of the lab template redeploy, and the same discipline applies: the target state is defined in advance (that is what starter sites are for), and the operation is recorded.
The guard rails: resets are destructive of current state by design, so they happen with the student's knowledge, after anything worth keeping is exported, and never during a marking window when the live site is evidence. Scoped, audited delegation — a lecturer resetting their own module's accounts, not roaming the estate — is the governance shape that makes this safe to offer at all.
How should accidental deletion and broken sites be recovered?
With a ladder students learn in week one, because both events are certainties at cohort scale. For deletion: check the obvious first (was it moved, not deleted?), then self-service restore of the affected files or database from the last good point, then support with specifics ('what, when') for anything beyond the panel's reach. For broken dynamic sites, diagnosis before restoration: a WordPress white screen after a plugin install wants the plugin deactivated, not an hour of restores — the fix-restore-reinstall ladder from the WordPress guide, with backups as the middle rung rather than the first.
The pattern across both: match the response to the actual damage. Restoring an entire account because one folder went missing destroys a day's other work; the granularity of the recovery should fit the granularity of the loss — a habit worth teaching explicitly, since it is exactly how professionals approach production incidents.
How should compromised sites be recovered?
By restoration to a pre-compromise point, never by hand-cleaning: infected sites hide persistence in places manual cleanup misses, so the reliable sequence is contain (restrict the account), identify when the compromise happened (logs, file changes), restore files and database to before that point, close the entry route (update the vulnerable plugin, rotate credentials) — and only then let the site back into the light. Restore-without-fixing just schedules the next incident.
This is the recovery half of the security guide's incident workflow, and it is also where backup depth matters: a compromise discovered late needs restore points from further back than yesterday, which is a question ('how far back can we go?') to settle with the platform during scoping rather than during an incident.
Read next: Student web-hosting security and abuse management
Why do assessment submissions need separate preservation?
Because backups expire and live sites change, while assessment records must do neither. Operational backups exist to recover recent loss, and their points age out on the platform's cycle; a live site keeps evolving (or breaking, or being reset) after the deadline. Neither is an assessment record. The submission — what was actually marked — needs capturing at the deadline as its own artefact: an export of files and database, an account moved to restricted read-only state through marking, a tagged commit where Git is in play, or several of these together.
The archive then lives on the academic clock (marking, appeals, retention policy — the retention guide's territory), not the backup cycle's. The one-sentence policy that prevents most disputes: 'marks attach to the submitted artefact, not to whatever the live site looks like later' — announced before the first deadline, applied without exception.
Read next: What happens to student websites after a course ends?
What should universities ask a provider about backups?
The scoping questions that turn 'backups included' into a working arrangement:
- What is backed up (files, databases, both) and on what cycle?
- How far back do restore points go, and what does that mean for late-discovered problems?
- What can students restore themselves, and what needs support?
- How long does a typical restore take — a file, a database, a whole account?
- How do restores behave during marking windows (can a restore overwrite evidence)?
- Are backups stored separately from the estate they protect?
- What is tested — when was a restore last actually performed?
- What happens to backups when an account is archived or deleted (retention alignment)?
The last two are the ones estates skip: an untested backup is a hope, and backups that outlive their retention policy are a data-protection finding waiting to happen. Any provider — Education Host included — should answer all eight plainly during scoping.