Use cases

Four concrete scenarios to illustrate what Caelum brings to daily operations. Each is described at the usage level (the benefit and the main steps), not at the fine-configuration level — for that, see the administration guide.

1. Archive cold data to the cloud, without losing access#

The need#

Your shares are overflowing with old files, rarely opened but impossible to delete (project archives, closed folders, regulatory data). They take up expensive local storage while almost never being opened.

What Caelum does#

Caelum tiers these cold files to an S3 object cloud of your choice, while keeping them visible and accessible in the share. When a user opens an archived file, it is recalled automatically from the cloud — no intervention, no manual re-download. You free up fast local storage without disrupting users.

In practice#

1. Run an audit of the share: Caelum shows the distribution by age and type, and identifies the archiving candidates.
2. Declare a cloud destination (the object cloud you chose, ideally hosted in Europe if sovereignty matters to you).
3. Define an archive policy: for example "files not accessed for 12 months are archived to the cloud", on demand or scheduled, on a share or a whole volume. The first run of a new policy is launched as a simulation (dry-run) to validate before the real archiving.
4. Cold files become stubs: they remain listed and open normally (an "offline" badge), the content being recalled on the fly. A large archived file can even be read by range over SMB (partial streaming) without recalling everything.

The benefit#

Less local storage to pay for, a clear view of what you archive, quantified savings in the Costs view, and zero change of habit for users.

2. Replicate to a remote site for disaster recovery (DR)#

The need#

In case of an incident on the main site (outage, disaster, ransomware), you must be able to restart from an up-to-date copy of the data, on another site.

What Caelum does#

Caelum replicates data to a second appliance on a remote site. Combined with snapshots (which let you return to a healthy prior state), replication gives you a remote copy usable for recovery. Each node keeps its own local pool; an asynchronous ZFS replication keeps the second node as a read-only mirror.

In practice#

1. Deploy a second Caelum appliance on the recovery site.
2. Configure replication of the relevant volumes to that appliance (frequency from 15 min to weekly, or a Continuous mode close to real time).
3. Maintain a snapshot policy on the source: in case of malicious encryption or an error, you restore from a healthy snapshot — including via Windows "Previous Versions".
4. You can verify the replica safely (read-only clone attached to a test volume), then, on the day, fail over manually to the remote node.

The benefit#

A remote copy of critical data and a fast rollback capability, without assembling a chain of heterogeneous tools: everything is driven from the Caelum interface.

3. Migrate from an ageing existing NAS#

The need#

Your current NAS is reaching end of life or end of support. You want to migrate the data to a modern platform — without breaking users' access rights or multiplying "I lost access to my folder" tickets.

What Caelum does#

Caelum first audits the source (volume, age, file types) to prepare the migration, then copies the data to the appliance. In an Active Directory environment, it strives to faithfully reproduce the domain's NTFS rights on migrated data. When full reproduction is not possible (for example without adequate administrative credentials), Caelum falls back to a safe mode that keeps data accessible without widening access beyond what is necessary.

In practice#

1. Audit the source NAS to understand the scale and nature of the data.
2. Launch the migration assistant to a Caelum volume.
3. Validate the result on a sample: check that the right domain users and groups have the expected access, before switching to production.

The benefit#

A controlled migration: you know what you are moving (prior audit), you preserve Windows permissions, and you validate before cutting over from the old system.

4. Consolidate or extend storage with an iSCSI array (SAN)#

The need#

You already have a storage array (SAN, enterprise NAS, Synology…) that exposes iSCSI LUNs, and you want either to reuse that capacity under Caelum, or to extend an existing deployment without starting over.

What Caelum does#

Caelum acts as an iSCSI initiator: it connects to a remote LUN, which then appears as a local disk usable to create a new pool or grow an existing pool. You can thus run a local primary pool alongside additional pools backed by the SAN, each hosting the volumes of your choice.

In practice#

1. In Storage → iSCSI targets, enter the array's portal (IP address, port 3260), run discovery, then connect to the target (optional CHAP authentication, the secret is never shown again).
2. The LUN appears as a disk: create a storage pool on it (protection level of your choice) or add it to an existing pool. For network-path redundancy, enable Multipath (MPIO).
3. Place your volumes on this pool like on any other.

The benefit#

You make use of an existing array and extend capacity without changing administration interface or disrupting the existing shares.

Combining the scenarios#

These scenarios stack. A common pattern: migrate an old NAS to Caelum, archive cold data to the cloud along the way to reduce local volume, and replicate the whole to a remote site for business continuity — all from a single interface.