Why Arkhivio

Arkhivio exists to solve a specific infrastructure cost problem. Not to replace existing backup platforms. Not to compete with them. To complement them — for workloads where a simpler approach makes more economic sense.

Why not use only an enterprise backup platform?

Enterprise backup platforms like Veeam, Rubrik, Cohesity, and Commvault are excellent tools — particularly for application-aware protection, orchestrated recovery, VM backup, and compliance workflows. If you have these workloads, you likely need these platforms.

The issue is that many organizations also use these same platforms to protect large volumes of file-based, historical, or archival data — NAS shares, file servers, archives — that does not require application-aware backup, instant recovery, or advanced orchestration.

When backup licensing scales with protected capacity, applying the same platform to every workload regardless of its actual requirements can create unnecessary cost. Arkhivio allows organizations to reserve enterprise backup capacity for the workloads that genuinely justify it.


Why not simply copy files to S3?

Copying files to S3 with rclone sync or aws s3 sync is straightforward — but it does not give you a backup. It gives you a copy.

Arkhivio adds the operational layer that turns an S3 copy into a managed backup:

Change detection

Tracks which files changed since the last run, using CRC32 checksums combined with modification time and size — not just timestamps.

Verification

Three-check integrity audit: MongoDB catalogue, S3 object metadata, and physical download with CRC re-computation. Drift is detected automatically.

History & state

MongoDB maintains backup history, run status, file state, and operational metrics — providing the operational record a simple sync tool does not.

Audit & reconciliation

The reconciler can detect files marked as backed up in MongoDB that are absent from S3, and vice versa. Structural drift is surfaced and addressable.

Managed restore

Selective or full restore with CRC verification on every downloaded file. Supports restore with MongoDB assistance or directly from S3 alone — no application required.

Observability

Structured JSON events from every operation. Alerts for upload failures, missing jobs, reconciliation drift, and credential issues. Integrates with existing monitoring stacks.


Why not use a traditional backup repository?

Most backup tools store data in a proprietary repository format. That format provides features — deduplication, compression, cataloguing — but it also creates a dependency: to access or restore that data, you need the backup software running and properly configured.

Traditional Backup
Your Files
Backup Software
Proprietary Repository
To restore:
need the software + license + repository intact
Arkhivio
Your Files
Arkhivio
S3-Compatible Storage
To restore:
any S3 tool — or restore_onlys3.py

Arkhivio intentionally stores files as standard S3 objects at deterministic, human-readable paths. There is no proprietary format to decode, no deduplication index to maintain, and no mandatory dependency on the Arkhivio application to recover your data. If Arkhivio is unavailable, you can access your files through any S3-compatible tool.

Object key format: {hostname}/{absolute/path/to/file}

Every file is at a predictable, reconstructable path. No look-up table required. No index to rebuild. Just files.


What is the relationship between Arkhivio and MongoDB?

Arkhivio uses MongoDB as its operational metadata layer. MongoDB tracks backup job state, file history, run metadata, and audit information. It is the control plane — not the data plane.

Arkhivio Architecture
Arkhivio
MongoDB
Control / Metadata
History · State
Audit · Tracking
Reconciliation
S3-Compatible Storage
Data Storage
Actual Files
Object Data
Inventory

MongoDB is not the backup repository. Your actual files live in S3-compatible object storage. MongoDB is unavailable? The data in S3 is unaffected and directly accessible.


Why does Arkhivio not implement its own deduplication?

This is an intentional design decision, not a missing feature.

Proprietary deduplication requires a proprietary repository. A proprietary repository creates a vendor dependency — the opposite of what Arkhivio is designed to avoid. To read or restore data from a deduplicated repository, you need the deduplication engine, its index, and its format documented and operational.

Arkhivio prioritizes direct file accessibility in standard object storage over storage efficiency achieved through proprietary mechanisms. If object-level storage efficiency is important for your use case, the underlying S3-compatible platform may offer its own capabilities (e.g., S3 Intelligent-Tiering, lifecycle policies, storage classes) without introducing a proprietary dependency at the backup layer.


What is Arkhivio not designed for?

Being specific about what a tool is not for is as important as what it is for.

Virtual machine backup. Arkhivio does not perform hypervisor-level snapshots or application-consistent VM backups.
Application-aware backup. Arkhivio does not perform VSS snapshots, database quiescing, or application-consistent protection.
Instant recovery or RTO orchestration. Arkhivio restores files — it does not orchestrate instant VM recovery or workload failover.
Replacement for enterprise backup platforms. Arkhivio is a complementary layer. Keep your existing platform for workloads that need it.

Want to see if Arkhivio fits your environment?

Follow the Quick Start to evaluate the product technically, or talk to us about your specific use case.

Talk to Us → Quick Start How It Works