Backup server

The backup is done. The backup server keeps working.

A plain backup program stores data and waits for the emergency. The AegisGrid backup server turns every incoming backup into the next step: check it, mirror it to a second location, export it to tape or USB disk, clean up, restore it as a test and inform the right people – automatically and traceably.

Diagram in five steps: a backup arrives encrypted from the computer, is checked (new or all stored data), mirrored to a second backup server and restored as a test, with VMs starting in the sandbox; finally a report with screenshots goes out by email. Every step is recorded in the evidence log: chained, signed daily, sent straight to your SIEM if you wish.
What the backup server does with an incoming backup – automatically and with proof.Swipe sideways to see the whole diagram.

Process further, automatically

  • Jobs at the start, after the success or after the failure of a backup, a mirroring or a restore
  • Check all stored data, or only what was newly added
  • Mirror to a second backup server, at another site, for example
  • Copy of whole stores to S3-compatible object storage, immutable if wanted
  • Export of single backups as an archive for tape or USB disk
  • Clean up by the retention rules, also by generations (days, weeks, months, years)
  • Your own scripts for everything else

Flows and dependencies

  • Flows of several steps that run one after the other – only on success or in any case
  • Waiting until certain backups or jobs have arrived
  • Schedules with public holidays per region, time windows and catching up on missed runs
  • Parallel jobs; whatever concerns the same store runs safely one after the other
  • Graphical view: which backup triggers which job
  • Sensible first jobs right after the installation

Check restores in the sandbox

  • Backups are restored as a test, regularly or as a sample
  • File systems are checked and mounted read-only, per disk and partition
  • Every file is read and compared with the last check – read errors, files changed unnoticed and losses are reported
  • Signs of ransomware in the backup, such as files that look encrypted or ransom notes
  • Virus scan with ClamAV, read-only: the report names since which backup a finding has been present and which backup was the last one without it; signatures also for backup servers without internet access
  • Virtual machines start in an isolated environment without any connection to the outside
  • Dependent systems in order, the domain controller first, then the mail server, for example
  • One check report per check chain: traffic lights per disk and partition, screenshots of the started machines

Messages to the right people

  • Errors, damage, missing backups, scarce storage and check reports
  • Per customer to its contacts for technical or commercial questions
  • For customers looked after by a partner, per kind of message to the customer, the partner or both
  • Clear texts with the next step, your own templates possible
  • Repeated messages are bundled instead of filling mailboxes
  • Recipients per kind of message, daily digest, preview and test email

Target console and web interface

  • Several backup servers in one interface
  • Running backups with computer, progress and time left
  • Running restores, Microsoft 365 backups and mirrorings with their progress
  • Data, backup versions and retention per store
  • History with charts of usage, results and throughput
  • Edit jobs, flows and schedules, view the evidence
  • Create check chains graphically: dock steps to disks and partitions, traffic light and progress per step
  • Access through its own HTTPS API with roles for reading and managing
  • Without Windows in the browser: overview, sessions, storage, accesses and customers, jobs, mail and log through the built-in web interface

Several customers on one server

  • Every access is bound to its directories
  • No customer sees the data or messages of another
  • Storage quotas per customer, with a notice before space runs out
  • Monthly evidence report per customer
  • Encrypted stores stay locked: checking, mirroring and cleaning up work without the key
  • Limits for CPU time, memory and disk access per job, so that no customer slows down the others
  • Usage measured per customer and job

Prove that the restore works

A backup is only worth something once it can be restored. The check restore checks this regularly without anyone having to lift a finger – every Saturday morning on three randomly chosen backups, for example.

  1. Restore

    The backup server restores the newest backup or a sample into a test area of its own.

  2. Check

    File systems are checked read-only; every file is read, compared with the last check of the same backup and examined for traces of ransomware and, if desired, for viruses.

  3. Start

    Virtual machines boot in the sandbox; the check looks at whether they run, show a screen or whether their services answer.

  4. Report and clean up

    The check report with traffic lights per disk and partition and screenshots goes out by email, is recorded in the evidence log, and the test area is emptied.

Everything that happens is on record

Every incoming backup, every restore, every job and every check restore is recorded in the evidence log of the backup server – chained, signed daily and, if you wish, handed to your SIEM at once. From it, a signed evidence report is created as a PDF every month.

Starting small works, too: for a single computer, a USB disk or a NAS is enough as the destination – without any backup server. The backup server comes in when several systems, a second site or evidence are needed.

Questions about the backup server

Do I need a backup server?

No. AegisGrid also backs up straight to a local disk, a USB disk or a NAS. A backup server pays off as soon as several systems come together in one place, backups are to go to a second site, or verified restores and evidence are needed.

Where does the backup server run?

On a Linux server of your choice – on site, at a second site or as part of our cloud storage. Several backup servers can be combined, one on site and one off site that mirrors the data of the first, for example. They are managed with the target console on Windows.

What does the check restore need?

Space for the restored data and, to start virtual machines, a backup server with hardware virtualisation (KVM). The check of the configuration names the packages needed. For encrypted backups, the backup server needs the key for the check restore; without it, checking, mirroring and cleaning up remain possible.

See the backup server in your environment

In a pilot project we set up further processing and check restores on your own systems.