For administration and engineering

Technology you can follow.

No black box: here is how AegisGrid works – from splitting the data through encryption and transfer to restoring whole virtual machines.

How a backup is made

Reading, chunking, hashing, compressing and writing run as a parallel pipeline. One run serves up to eight destinations; the source is read only once.

  1. Read consistently

    VSS shadow copy on Windows, LVM snapshot on Linux, plus freely selectable pre/post hooks for databases and applications. Free areas of NTFS and ext2/3/4 are skipped.

  2. Chunk by content

    FastCDC splits the data into chunks of 256 KiB on average. Moved or inserted data only changes the chunks affected.

  3. Check and compress

    Every chunk gets an ID (SHA-256, BLAKE3 or XXH3-128). Only unknown chunks are compressed with zstd or lz4 and encrypted.

  4. Transfer securely

    The agent streams over TLS to the backup server, whose certificate is pinned. Only what the destination is missing is transferred.

Technical data

DeduplicationContent-defined (FastCDC), chunk size 256 KiB on average, adjustable per store; deduplicated across all backups of a store, also across computers
Chunk IDsBLAKE3 (default for new stores), SHA-256 (hardware-accelerated) or XXH3-128; with encryption, key-dependent IDs
Compressionzstd (default, optionally with an adaptive level), lz4 or none – per chunk
EncryptionAES-256-GCM or ChaCha20-Poly1305 per store; key as a file, directly or through a key service
TransferTLS with certificate pinning, API keys per directory, automatic reconnection after a lost connection within the same run
Resump­tionAlways active: a state file per job, continuation after a crash, shutdown or power failure at system start; the snapshot or persistent shadow copy is kept where possible; only what the destination is still missing is transferred
Backup serverLinux; privileged parts separated, data processing runs under a separate, unprivileged account; its own scheduler for jobs on events, on a schedule and in flows
Check restoreRestore as a test, read-only file system check (ext2/3/4, xfs, btrfs, vfat, ntfs, LVM in the image) per disk and partition, counting with a loss threshold, reading every file with a checksum (SHA-256, BLAKE3 or XXH3-128) and comparison with the last check, ransomware signs (file signature, entropy, extensions, ransom notes), VM start in QEMU/KVM without a network or in an isolated network, check by screen, guest agent or TCP port, one report per check chain with traffic lights and screenshots
EvidenceLog as JSON Lines with a SHA-256 chain, daily Ed25519 seal, copy via syslog (RFC 5424, UDP/TCP/TLS) or to a second backup server, export as CSV/JSON and a monthly report as a PDF, each signed
ConsistencyVSS (Windows), LVM snapshots (Linux), pre/post hooks
Kinds of backupFiles, volumes, partitions, whole disks, images; zero areas are recorded as gaps and not stored
ProtectionWORM locks, check of all objects (scrub), repair from a second copy, mirroring of whole stores, export of single backups as an archive
RestoreEvery version on its own, parallelised; partial restore even of damaged backups; VMs as a new VM or disk by disk, also directly from the server; Proxmox and Xen VMs also in place, optionally only changed blocks
Operating systemsWindows and Linux for agent, restore, job scheduler and updates; backup server on Linux; management console and target console on Windows; web interface for job scheduler and backup server in the browser

Virtualisation and cloud

Virtual machines are backed up as a whole: all disks and the configuration in one run.

Hyper-V

The basis is a recovery checkpoint, application-consistent through VSS in the guest. All virtual hard disks and the state files including vTPM are backed up. Thanks to Resilient Change Tracking, follow-up backups only read changed areas.

Proxmox VE

Whole VMs with all disks, UEFI variables, vTPM state and configuration on LVM, LVM-thin, ZFS, Ceph RBD and qcow2 (directory, NFS, CIFS). With the QEMU guest agent, the guest is briefly frozen across all disks together. Thanks to change tracking (CBT), follow-up backups read only what changed. Restore as a new VM, disk by disk or in place.

Xen

VMs on Xen (xl) with all disks and configuration, short freeze windows for the guest, restore as a new VM or in place.

Microsoft 365

Through Microsoft Graph with an app registration of your own in Entra ID: mailboxes with mail, calendar, contacts and tasks, OneDrive and SharePoint – incremental, for single accounts or the whole tenant, with export of single items.

Automation and operation

The job scheduler runs as a service on Linux and as a Windows service on Windows. It starts jobs on a schedule or by dependency, also in parallel, and sends results by email.

Through the documented HTTPS API, jobs can be created, started, paused and monitored – ideal for your own tools and monitoring. The backup server has its own HTTPS API with roles for reading and managing; if you wish, its evidence log goes straight to your SIEM via syslog.

  • Progress, pause and bandwidth limit for running backups
  • Maintenance jobs for clean-up, checks and mirroring, on the backup server triggered by incoming backups
  • Schedules as cron or RFC 5545 rules, with holiday calendars, time windows and catching up on missed runs
  • Configuration changes through the API by email with the changed lines, earlier versions kept
  • Installation by setup, updates signed and scheduled
  • Diagnostics package with one command for support
  • Progress display on the Windows desktop

Questions from administrators

How does deduplication work in AegisGrid?

AegisGrid splits the data by content with FastCDC into chunks of 256 KiB on average and computes an ID for every chunk. Only chunks whose ID does not yet occur at the destination are stored and transferred. This applies across all backups of a store, also between different computers.

What happens if the connection drops during a backup?

The next backup continues where the interrupted one stopped; chunks already transferred are not sent again. If one optional destination of several fails, the others keep running.

Are there chains of full and incremental backups?

No. Every backup is a complete version that can be restored on its own. The labels “full” and “incremental” are only for orientation; internally there are no dependencies between the versions.

How do I get a deleted file back?

In the management console: choose the backup, choose the point in time, tick the files, write them to the original location or to another folder. On the command line, bkp_restore --list shows all backups of the computer and bkp_restore --sinks which destinations can be reached right now. --files find "*offer*" searches across all versions, --files versions shows the versions of a file, --files restore … --original writes it back. If the search finds nothing, it names the likely reasons, such as an exclusion or a folder outside the backup.

Talk to the developers

Technical questions are answered by the people who build AegisGrid.