A backup is not reliable merely because another copy exists somewhere. A copy can be outdated, incomplete, overwritten by synchronisation, inaccessible to the people who need it, or impossible to restore into a usable state. The real test is recovery.

This article uses ordinary school and project files. For organisational or regulated systems, follow the authorised backup, retention and security procedures rather than substituting a personal workflow.

The copied folder that copied the mistake

Imagine Clara keeps a project spreadsheet in a synchronised folder. She accidentally deletes an important worksheet. A minute later the deletion synchronises to her laptop and tablet.

She had three copies, but all three now reflect the same current state. Redundancy of location did not provide an earlier version.

Synchronisation is useful for keeping devices aligned. That is a different job from preserving recoverable historical states.

Define what must be recoverable

A project may consist of more than the visible document: source data, images, citations, configuration, linked files and notes can all be required to reproduce the final work.

Backing up only the exported PDF preserves a presentation but not necessarily the editable project. Backing up only the spreadsheet may omit the original data collection record needed to audit a correction.

List the minimum set required to continue the work after loss. That list defines the backup job.

A backup needs a time dimension

If today’s file is damaged, another copy of today’s damaged file is not enough. Recovery may require yesterday’s or last week’s state.

Version history, snapshots or dated backups provide this temporal separation when configured appropriately. Retention matters: a system that keeps versions for only a short period may not help when corruption is discovered months later.

Choose retention according to how quickly problems are likely to be noticed and the value of older states. More history has storage and governance costs; too little history can make delayed discovery unrecoverable.

Do not call the file “final” and expect identity to survive

Names such as final, final2 and final-really-final do not establish which version contains the approved work. Use dates, version identifiers or a managed history appropriate to the project.

Keep the authoritative working location clear. A backup should preserve versions without creating several competing files that collaborators edit independently.

The article When Are Two Things the Same? develops the broader distinction between identity, copies, versions and aliases.

Access is part of recovery

A backup stored in an account nobody can access after the owner leaves is operationally weak. So is an encrypted archive whose recovery information has been lost.

For shared work, authorised people need a documented route to recovery without exposing private material to everyone. Availability and confidentiality must be designed together.

Do not solve access risk by sharing passwords in documents or chats. Use the account and permission mechanisms provided by the service.

A successful backup job can still produce unusable files

An automated process may report success because files were copied. The archive can still be truncated, corrupted or missing dependencies.

Verification should check more than file count. Can representative files be opened? Are expected sizes and dates plausible? Can the project be reconstructed from the captured material?

Checksums and integrity tools can detect some forms of corruption, but they do not prove that the correct files were selected in the first place.

The restore test is the real rehearsal

A restore test retrieves a backup into a safe location and checks whether the recovered material can actually be used. It should not overwrite the live project merely to demonstrate confidence.

For a simple school project, this may mean restoring a copy of the folder and opening the spreadsheet, images and source notes. For a complex system, recovery testing requires the organisation’s approved procedure.

Record how long recovery took and what was missing. A backup that technically works but takes longer than the project can tolerate may need a different recovery design.

Offline and separate copies protect against shared failure

If every copy depends on the same account, service or synchronisation process, one failure can affect them together. Separation reduces common-mode risk.

The familiar “3-2-1” backup heuristic—multiple copies, different media, and one copy separated from the primary environment—is a useful starting idea, but implementation depends on the system, sensitivity and threat model.

Do not create uncontrolled portable copies of sensitive student or organisational data merely to satisfy a slogan. Security requirements still apply.

Backups should not become another source of privacy loss

Old backups can retain information long after it disappears from the live folder. That can be useful for recovery and problematic for retention obligations.

Know what personal information is being preserved, who can access it and when old versions should expire under the applicable policy. Recovery value does not eliminate privacy responsibility.

For ordinary schoolwork, minimise unnecessary personal data in the first place. A backup of a pseudonymous dataset is easier to protect than a folder filled with names and unrelated identifiers.

Recovery point and recovery time are different

One question is how much recent work could be lost. Another is how long it takes to resume work after a failure.

A daily backup can leave up to roughly a day’s new work outside the latest successful backup, depending on timing. A backup stored in a slow archive may preserve the data while taking substantial time to retrieve.

Choose backup frequency and recovery process according to the value and pace of the work. A rapidly changing collaborative project may need different protection from a finished reference document.

The repair routine

Identify the authoritative project and everything required to reconstruct it. Decide how much recent work you can afford to lose and how long recovery can reasonably take.

Create versioned, appropriately separated copies using approved storage. Verify that the expected material is captured. Periodically restore representative data into a safe location and document problems.

Review access, retention and privacy. A recovery system that exposes sensitive data or cannot be used by authorised people has solved only part of the problem.

For spreadsheet integrity, continue with Why Sorting One Spreadsheet Column Can Ruin Your Results. For version identity, use When Are Two Things the Same?.

The comforting sentence “we have a backup” is not the end of the question. The useful sentence is “we know which state we can recover, from where, and we have tested that the recovery works.”