The only way to check your company's backups is to restore them: select the data you need, restore it separately from the live system and confirm that it is usable. Record the backup date, the result and the actual time taken for the check. A successful backup job confirms that a copy was created, but does not yet prove that the company can resume work.

Why is a "backup completed" message not enough?

The software may successfully save a selected folder while the database you need is somewhere else. Files may copy correctly, but the application may not open them without settings, an encryption key or a compatible version. Check the entire chain, from the data inventory to a working result an employee can verify.

Ask to see the last successful backup and the latest restoration test record. These are different records. The first shows whether the job ran successfully. The second shows what was recovered and how it was checked. Without a test record, restoration remains unverified even if the job log looks reassuring.

Define in advance how much recent work can be lost and how long an interruption is acceptable. These are business requirements. They help determine backup frequency and the order in which services are restored. Do not set identical requirements for every folder: a live database, a document archive and temporary files have different operational value.

What does the 3-2-1 rule mean in plain language?

It is a basic storage arrangement: three copies of the data, including the working copy; two different types of media; and one copy away from the main site. The aim is to prevent one fault or incident from affecting everything at once. Adapt the arrangement to your systems, data volumes and restrictions on where information can be stored.

Two folders on the same disk do not offer independent protection against disk failure. Cloud synchronisation does not always replace backups either: deletions or corruption may also reach the cloud folder. Check version history, retention periods and whether you can return to the state before an error.

Discuss separately how backups are protected against deletion through a compromised account. The right measure depends on the platform: separate permissions, removable media or immutable storage. The 3-2-1 rule describes where copies are kept, but does not confirm that you can access them and restore the application.

Which seven questions should you ask your system administrator?

Go through this checklist with the responsible specialist. Ask to see the result on screen or in a document without exposing passwords. "It was configured a long time ago" leaves the question open: a server move, application change or employee departure may have made the previous arrangement unsuitable.

  1. What exactly is backed up? Compare the list with current databases, documents, email, the website and service settings.
  2. How often are backups created? Ask for the date of the latest successful copy, the history retained and the rules for deleting old versions.
  3. Where are the copies? Clarify whether they would survive a main-site failure and an administrator's mistake.
  4. Who has access? Assign a primary and a backup responsible person, and check that instructions and keys are available through secure storage.
  5. Who receives error messages? Show the recipients, response procedure and checks for a missing expected backup.
  6. When was a restoration test performed? Ask for a record showing the selected date, data covered, result and observations.
  7. What happens during an incident? Check the system startup order, contractor contacts and how work continues if the main server is unavailable.

Assign an action and a responsible person to each gap. This turns the checklist into a working plan. Do not substitute a large report for verification: one confirmed restoration scenario for a critical system is a more useful starting point than a list of settings without a result.

How can you test restoration without disrupting operations?

Agree the scenario with the specialist and the process owner. Choose a backup from the required date and define success criteria beforehand. For documents, open the files and check their contents; for an application, start it, sign in and check the operational data. Merely checking that files exist on disk is insufficient.

Restore into a separate environment. Before starting, prevent connections to the live database, automatic mailings, exchanges with external systems and jobs running on the company's behalf. The test must not overwrite live data or send documents to clients. Use the minimum necessary information and restrict participant access.

  1. Record the chosen backup and the test start time.
  2. Restore the data according to the instructions, including the required settings.
  3. Check startup and contents with a user of the system.
  4. Record the time taken, errors and manual steps missing from the instructions.
  5. Agree corrections, repeat the failed stage and safely remove the test data.

A quarterly schedule can be a starting point for planned checks. Choose the frequency according to risk and changes: a server migration, application update or change in backup method calls for an additional test. Quarterly restoration checks do not mean creating backups only once a quarter.

Which alerts and records does a manager need?

Check alerts for failed jobs, insufficient space and missing expected backups. Every message needs a recipient and a clear next step. If an alert goes to a former employee's mailbox or gets lost among service emails, technically successful delivery does not help anyone spot the problem.

Ask the specialist to test alert delivery safely without stopping backups. Agree how investigation of an error is recorded and who takes over if the main responsible person is absent. A lost connection to the backup system also needs attention: silence does not confirm success.

A short record should identify the system, backup date, test date, restoration method, result, time taken and outstanding problems. Compare the result with business requirements. If restoration depends on one person, expand the instructions and prepare someone to cover for them.

How is this organised at Credus Clinic?

For Credus Clinic, we built multi-layer backups with alerts, a dedicated server environment and an isolated environment for the medical system. Service data is backed up, and separate recovery scenarios cover serious failures.

Backups are connected to access management, monitoring and alerts, so a failed job does not go unnoticed. For your company, start with the seven questions above and one restoration test. Access and backup management covers storage arrangements and responsibilities; server support in Almaty covers the server side.