Backup, restore, and disaster recovery

Protect AtomOS vault data and plan recovery before you need it. Define RPO (acceptable data loss) and RTO (time to restore service) per workload class.

Backup success ≠ verified recoverability

A completed backup job only proves that data was copied according to the job definition. Recoverability means a tested restore that boots the guest and passes application checks. Schedule restore drills on non-production data.

Consistency models

Ordinary file copies of a live virtual disk are not a crash-consistent point-in-time image. While the guest writes, different regions of the file can be copied at different moments, so the restored image may contain torn writes even for a “crash-like” failure model.

Approach	What you get	Typical use
File-level copy of inactive disks	Consistent with guest shutdown (or disks not open for write)	Planned maintenance backups
Live file copy without snapshots	No consistency guarantee — torn pages possible	Avoid for databases and any tier-0 data
Atomic storage snapshot	Point-in-time at the storage layer (backend-dependent)	ZFS/array snapshots when your backend supports them
Crash-consistent snapshot	Approximates sudden power loss if the snapshot is atomic and coordinated	Hypervisor or storage snapshot with verified semantics
Guest-quiesced snapshot	Filesystems frozen / VSS coordinated where supported	Better guest filesystem integrity
Application-consistent backup	Databases and apps flush and coordinate (VSS writers, dump tools, etc.)	Tier-0 transactional workloads
Hypervisor-integrated VM backup	Backup product talks to the hypervisor / guest agent stack	Product-specific; not the same as SSH file-level vault backup

Hot vault file backup

Do not treat a running file-level copy of vid.<id>.elimg / data.* as crash-consistent or application-consistent. Prefer guest shutdown, a validated quiesce path, or a snapshot/integration you have tested for that workload.

Safe approaches for AtomOS vault data (when product-specific snapshot/quiesce workflows are not documented for your release):

1. Shut down the guest (or stop I/O to the volume) before backing up its vid.*.elimg tree.
2. Use application-aware tools inside the guest (database dumps, VSS-aware agents) in addition to vault protection.
3. Use storage-level snapshots only if your vault backend provides atomic snapshots and you have validated restore.

AtomOS public docs do not claim a built-in guest-quiesce or hypervisor-aware Veeam path as equivalent to the file-level procedure below. Confirm additional integrations with Elemento before relying on them.

Backup product roles (Veeam)

When using Veeam Backup & Replication, keep these roles distinct:

Role	Responsibility
Backup & Replication server	Job orchestration, configuration, and metadata
Console	Operator UI connecting to the server
Managed Linux server	AtomOS host added over SSH for file-level path backup
Veeam Agent	Optional guest or host agent workflows (separate from Linux file-level server backup)
Repository	Where backup files are stored (must not be the primary vault disk alone)
Proxy	Optional data-mover component in larger Veeam designs
Hypervisor-aware integration	Backup via hypervisor APIs / CBT-style integrations — different from vault file-level backup

AtomOS contribution: vault layout under /mnt (default /mnt/elemento-vault/), volume directories named vid.<id>.elimg, and host SSH access for file-level jobs.

Veeam contribution: job scheduling, retention, transfer, and repository management. Platform support for Windows or Linux components must follow your Veeam product version documentation — do not use end-of-support desktop OSes as a new enterprise baseline.

Platform baseline

Use a currently supported Windows Server or Linux platform approved by your Veeam version for the backup infrastructure. Tutorial videos linked below may show older worker OS choices for historical context; treat them as walkthroughs of the file-level vault flow, not as current OS recommendations.

Three paths that must not be conflated

Approach	Scope	Documentation status
1. Veeam Linux file-level of vaults	SSH to AtomOS; backup paths under /mnt	Documented below
2. Hypervisor-aware Veeam	Backup through hypervisor integration	Separate product path — not equivalent to vault file restore semantics
3. Electros-native Veeam management	Orchestration inside Electros	Not documented as available in this revision — ask Elemento before design commitments

RPO / RTO planning

1. Classify workloads (critical databases vs general VMs vs lab).
2. Set RPO/RTO per class.
3. Match method to class — live file-level alone is inappropriate for tier-0 databases.
4. Store backups off the primary vault media.
5. Test restore before production reliance.
6. Include every active vault under /mnt.

Procedure: Veeam file-level backup of AtomOS vaults

Objective

Back up AtomOS volume directories so you can restore whole vid.<id>.elimg folders (payload + metadata).

Supported environment

• AtomOS host with vault mounts under /mnt (default /mnt/elemento-vault/).
• Veeam Backup & Replication with Linux managed-server / file-level backup capability for your licensed version.
• Network path from the Veeam infrastructure to the AtomOS management or bridge address you intend to use.

Prerequisites

• SSH access with a user that can elevate (commonly wheel on AlmaLinux/Rocky).
• Inventory of vault paths and volume IDs to protect.
• Guests stopped or otherwise quiesced when consistency is required.
• BMC/console access if you change networking for the worker.

Risk

• Backing up live disks can produce unrestorable or silently corrupt images for applications.
• Restore overwrites vault content — confirm IDs and paths before writing.

Worker / infrastructure VM

1. Deploy a Veeam-supported Windows Server or Linux system for the roles your design needs (server, console, proxy as applicable).
2. For a Windows guest used as a LAN worker toward AtomOS hosts: attach VirtIO drivers; prefer VirtIO NIC for throughput.
3. Place the worker so it can reach AtomOS SSH endpoints (Networking).

Add the AtomOS host in Veeam

1. Open Files → Add Server → Linux (labels may vary slightly by Veeam version).
2. Enter the AtomOS IP (often the address on br0 or the management path to the host).
3. Provide SSH credentials with elevation for vault path access.
4. Select vault paths under /mnt (default /mnt/elemento-vault/). Repeat for every vault in scope.

Backup job

1. Create a Linux / file-level backup job against the managed server.
2. Name the job with site and vault identifiers.
3. Select the vault path(s).
4. Set schedule, retention, and repository for your RPO/RTO.
5. Prefer jobs that run when target VMs are powered off, or accept that live jobs are not consistency-safe.

Expected outcome

Job completes with vault trees (including vid.<id>.elimg) present in the repository according to retention.

Verification (backup)

• Job logs show success for all selected paths.
• Spot-check that recent vid.* directories appear in the repository.
• Record which VMs were running vs stopped during the job.

Procedure: restore a volume folder

Prerequisites

• Confirm the target VM is stopped.
• Confirm volumes are not actively exported or attached in a conflicting way on the restore host.
• Identify the correct vault mount (for example /mnt/elemento-vault/).
• Have the full vid.<id>.elimg folder from backup (payload data.* and metadata).

Steps

1. Restore the entire vid.<id>.elimg directory into the intended vault path (replace <id> with the real volume directory name from inventory).

2. Preserve ownership and permissions expected by AtomOS storage (match neighboring volume directories on a healthy host).

3. Inspect with (use a real volume ID from your vault; the value below is only an example):

   # Example identifier only — replace with a real vid.* directory name from the vault
   VOLUME_ID="example-volume-id"
   sudo atomos-cli --volume-info
   ls -la "/mnt/elemento-vault/vid.${VOLUME_ID}.elimg"

4. Re-attach or recover the volume through Electros or AtomOS GUI using the supported volume/VM workflow for your release.

5. Power on the guest and confirm boot.

6. Run application-level consistency checks (filesystem check if appropriate, database recovery, service health).

Failure handling

• If the volume does not appear, check vault mounts, settings.json via atomos-cli --vault-editor (do not hand-edit blindly), and storage service status (atomos-cli --restart storage only in an approved window).
• If the guest fails to boot, keep the restored tree and escalate with support@elemento.cloud rather than overwriting again.

Product-specific recovery steps

Exact Electros “re-register volume” UI labels and any forced export/reset APIs are release-specific. Prefer Electros/GUI operations over manual libvirt edits (Diagnostics).

Walkthrough videos (historical file-level flow; OS baselines may be outdated):

• Create and configure the VM
• Create a backup job
• Backup restore

Bare-metal and DR outline

Scenario	Typical order
Lost volume only	Restore vid.<id>.elimg into vault; reattach VM; verify boot and apps
Lost compute host	Replace/reinstall host; restore vaults or reconnect shared storage; register in Electros; restore or recreate VMs
Lost site	Bring up DR hosts and network; restore vault data; DNS; certificates; validate

Accidental deletes may still exist under elemento-bin retention — define cleanup policy before production (Storage).

Related reading

• Migration & import
• Upgrades
• Availability & recovery
• Install with atomos-cli