How NubliVault works

Who it is for

Service providers, integrators and companies that keep large file estates in the cloud — documents, images, invoices, reports — and need a cheap, secure backup with single-file recovery. The solution is multi-tenant: it serves many end clients with full isolation between them.

The problem it solves

Traditional backup copies object by object. With millions of small files, the cost does not come from the space used — it comes from the number of write operations and the price of the tier where the data sits. NubliVault attacks both:

• Groups each client's files into a few compressed packages, cutting write operations by ~99.98%.
• Moves those packages to archive tiers, where storage costs a fraction of the price.
• Keeps a searchable index, so you can recover a single file without downloading the whole package.

Architecture

The pipeline is entirely streaming — it never loads a whole bucket into memory or disk:

• Paginated reads from the source buckets, in blocks of one thousand objects.
• Per-client packaging and compression, with deduplication and incremental sync.
• Multipart upload to the destination, in the lowest-cost tier.
• Indexing of every file per client, with its position inside the package.
• Deletion lock at the destination, guaranteeing immutability of what has been written.

Prerequisites

You need access to both ends — the cloud where the backups live today and the cloud where they will be archived:

• Read credentials on the source buckets (OCI, AWS, GCP or Azure).
• A destination bucket with object lock enabled, in the customer's account.
• A machine for the agent, close to the source data, with working disk sized for the largest package.
• Optional: your own encryption key (BYOK), managed in your cloud's key vault.

Deployment

The agent ships as a container and starts with a single command. The web console follows the installation and becomes the operations hub: client registry, source and destination connections, scheduling and live job tracking.

Day-to-day operation

Once configured, the normal flow is automatic — the scheduler runs the incremental backup and the console notifies on failure. The most common manual actions:

• Dry run: estimates volume, package count and savings before moving any data.
• Backup: triggers packaging for one client or an entire bucket.
• Recovery: finds the file in the index and restores it to the chosen destination.
• Audit: reviews who did what, filtered by action and period.

Disaster recovery

Because packages sit in an open, standard format with a readable index, you can recover them independently. In a disaster scenario the console is rebuilt from a ready-made image and the database backup, and processing capacity scales on demand — the data never depends on the source being up.