Task guide

This guide dives into the routine operations of administering a Caelum appliance. It complements the administration guide (which describes each screen) by focusing on the "how to" of the most frequent tasks, end to end. The basic notions (volume, share, S3 target, tiering, snapshot) are explained in the product overview.

Create and manage volumes and shares#

Create a volume#

A volume groups shares that follow the same rules (quota, snapshots, default S3 target). To create one:

1. Go to Volumes → New Volume.
2. Give it a name (lowercase, digits, dash, underscore — it serves as the internal dataset name).
3. Set a quota (in GiB) or leave it empty to allow the whole pool.
4. Choose the target pool (primary by default, or an additional pool).
5. Optional: choose a default cloud destination and an S3 retention (how long objects are kept after being deleted on the share side).
6. Enable Previous Versions (Windows) if you want to expose snapshots as "Previous Versions" (see the dedicated procedure further down).

Best practice: one volume per team or per project, which lets you apply distinct quotas and snapshot policies.

Create a share#

1. From a volume's card (Volumes view), click Add Share.
2. Give it a name: it becomes the SMB access path \\<appliance>\<name>.
3. Choose the protocols served: SMB and/or NFS, with an optional read-only flag.
4. Restrict access if needed:
   • SMB: a list of allowed groups/users (Active Directory or LDAP). Left empty, the share is served to local accounts; if the appliance is joined to a domain, all domain users have access by default.
   • NFS: a list of allowed IP addresses / CIDR.
5. Optional: a disk quota specific to the share, and a specific S3 target and retention.

The share then appears in the list with its path, its file count and its volumetrics (apparent size, actual size on disk, and the savings obtained from archiving).

Manage an existing share#

Click a row in the share list to open its detail. The available tabs:

• Info: configuration and statistics (files, stubs, last scan).
• Explorer: browse the tree.
• HSM / Tiering: the share's archiving status (read-only; archiving is driven through the archive policies).
• Snapshots: snapshots of the parent volume.
• Activity: recent activity.
• Quotas: disk limits.

The share also exposes advanced SMB options (enterprise / AD): NTFS ACL, Access log (SIEM), Forced SMB3 encryption and Offline files (CSC client cache: Disabled / Manual / Documents / Programs). Deleting a share offers to delete the data and the S3 copies, and closes active SMB sessions.

To modify protocols, access or quotas, use the share's edit button. SMB/NFS access changes take effect without interrupting current sessions.

Advanced storage: pools, iSCSI and role-based networks#

Add an additional storage pool#

Beyond the primary pool (galilopool, mounted under /galilo/data), you can create additional pools (mounted under /galilo/pools/<name>) to place certain volumes on separate storage.

1. Go to Storage pools → Create a pool.
2. Give it a name, select the disks, then a protection level: Single, Mirror, RAIDZ1, RAIDZ2 or RAIDZ3.
3. Confirm the summary. When creating a volume, then choose this pool as the target.

You can also import an exported pool. To replace a disk, select the failing disk and the new disk: the rebuild (resilver) is non-disruptive.

Attach an iSCSI LUN#

To use a LUN from a remote array (e.g. Synology) as a pool disk:

1. Go to Storage → iSCSI targets.
2. Enter the portal (IP or IP:port, 3260 by default) and click Discover.
3. If necessary, provide CHAP authentication (the secret is write-only).
4. Click Connect: the LUN appears as a disk to create or extend a pool.

Disconnecting is refused if the LUN belongs to an imported pool. Multipath (MPIO) is configured in the interface (editing /etc/multipath.conf), without SSH.

Assign role-based networks#

To dedicate network cards to specific uses (System → Network → Role-based networks):

1. Assign each card a role: Management (UI/SSH), Data (SMB/NFS), Cluster (HA heartbeat), Replication, Cloud/S3 or iSCSI storage. All-in-one / Separate networks presets are offered.
2. The assignment automatically wires the services' binding and the HA VIP.
3. For an advanced configuration (LACP 802.3ad, VLAN 802.1Q), use the "Test for 60 s (auto rollback)" button: the config is applied and then restored on its own if you don't confirm (anti-lockout).

Configure a cloud destination and archiving#

Declare a cloud destination#

1. Go to Cloud destinations → Add a destination.
2. Fill in:
   • Name: a label.
   • Server address (host without scheme, e.g. s3.eu-west-3.amazonaws.com) and port.
   • HTTPS and TLS certificate verification: keep enabled in production (only disable verification in a lab).
   • Access key / Secret key: the secret is never shown again after saving.
   • Region and Bucket: the bucket must exist (it can be created/selected from the interface).
   • Cost (€/GB/month): used by the Costs view to estimate your savings.
3. Save. The destination becomes selectable as a default destination for a volume or a share, and in archive policies.

Create an archive policy#

Archiving is driven from the Archive policies view (which merges the former "Rules" and "Tasks"). A policy is a named, reusable task = filter + action + destination + schedule + scope.

1. Open Archive policies → the "Archive to the cloud" wizard.
2. What: file eligibility criteria (age, size…).
3. Where: the cloud destination.
4. When: a daily / weekly / monthly schedule.
5. Scope: global, per volume or per share (scopes add up, with deduplication per destination). Confirm the safeguards.

Once archived, a file becomes a stub (offline file): it stays visible and clickable, marked offline under Windows (cloud badge), but takes almost no local space. When opened, Caelum recalls it from the cloud, transparently. A recalled file that has gone cold again can be re-archived. For large media, a partial streaming over SMB lets you read a stub without fully recalling it (the "▶ Play" button in the explorer).

The HSM / Tiering tab of a share's detail is read-only: archiving is triggered through policies and right-clicking in the Explorer.

"S3 Cache" mode (cloud-backed NAS)#

Some shares can run in S3 Cache mode: the source of truth is the S3 bucket, and the appliance keeps only a buffer of recently used files locally (a grace period before eviction and an occupancy cap). This is the mode suited for when your data already lives in object storage and you want to give it a fast SMB/NFS access without fully recalling it. Enable the option at the share level and associate the matching cloud destination.

Snapshots and "Previous Versions"#

Schedule snapshots#

1. Go to Snapshots → New.
2. Choose the target volume/dataset.
3. Set the frequency (hourly, daily…), the number of snapshots kept (automatic rotation) and the Recursive option (includes child datasets).
4. Enable Windows Previous Versions compatible so snapshots appear on the Windows side.

A snapshot of the volume covers all its shares. It is near-instant and only occupies the space of later changes.

Enable "Previous Versions" (a single checkbox)#

Exposing earlier versions to Windows is managed by a single toggle — on a volume or a share:

1. Open the volume (or the share) and enable "Enable Previous Versions".
2. Caelum provisions the whole chain (Samba exposure + self-managed snapshot scheduling). Nothing else to configure.
3. Optional: expand the advanced options to adjust the frequency (hourly / daily / weekly) and the number of snapshots kept (default 24).

Disabling the checkbox cleans up the configuration. An inconsistency safeguard flags an incomplete chain, with a one-click fix.

Restore via "Previous Versions"#

Once the option is active, a Windows user can, from the Explorer:

1. Right-click a file or folder → Properties.
2. Previous Versions tab.
3. Select an earlier version and restore or open it.

On the administrator side, snapshots are managed and restored from the Snapshots view.

Replication and disaster recovery (DR)#

Replication copies your volumes to a second Caelum appliance (remote site), for disaster recovery. Sends are incremental (only changes transit) and are done per volume. The full detail (pairing, frequencies, continuous mode, ACL fidelity) is in the replication guide.

Set up a replication target#

1. Go to Replication → New target.
2. Fill in the name, the address (IP or DNS) of the remote appliance, the SSH user and the port.
3. Click Test & detect: the appliance checks connectivity and offers pairing (authorizing the SSH key via an HTTPS 443 admin session, without storing any password).
4. Optional: network compression (useful on a slow WAN link) and a forced source IP if you have a dedicated replication network.
5. Create a job per volume to replicate, with its frequency (from 15 min to weekly, or Continuous mode ~15 s / real-time RPO).

Verify a replica ("Verify replica")#

On the destination side, received datasets appear under "Incoming replications". The "Verify replica" action (formerly "Mount as DR") clones the last snapshot in read-only, attached to a dedicated DR volume, to check data integrity without disrupting the flow. "Mount as DR" then recreates the real shares; "Stop the test" destroys the clone.

Fail over for disaster recovery (HA — Option A)#

When replication is integrated into high availability in replication mode ("Option A"), failover is done in one gesture, from the High availability tab:

1. Check that the last received replication is recent (acceptable RPO).
2. Click "Fail over (failover)" and confirm the acknowledgements.
3. The secondary node is promoted to Primary: its volumes switch to read-write, the shares are served and replication reverses automatically toward the former primary.

Active Directory / LDAP join#

To authenticate SMB users with the company's accounts.

Join an Active Directory domain#

1. Domain view (or System → User accounts (SMB)).
2. Fill in the Realm (e.g. CORP.EXAMPLE.COM), a domain administrator account and its password (used only for the join, not stored in clear), and optionally the domain controller.
3. Click Join.

Once joined, AD users and groups become listable and usable in share access restrictions. To leave the domain, use Leave the domain (an operation that removes the machine account; AD-based access will stop resolving).

LDAP (without Active Directory)#

Two options, in System → User accounts (SMB):

• Embedded local LDAP: an internal directory in the appliance to manage SMB users without external infrastructure.
• External LDAP: connect to an existing directory (OpenLDAP, 389DS, FreeIPA…). Fill in Host, Port, Base DN, Bind DN and the bind password; TLS (LDAPS/StartTLS) available.

High availability (HA)#

HA lets two appliances take over from each other. The "Choose the HA mode" screen offers two distinct modes; a shared-disk detection assistant compares the physical identifiers (WWN/serial) of the two nodes' disks and recommends the suitable mode.

Mode 1 — Shared storage#

• Prerequisites: a single ZFS pool on a LUN/SAN (iSCSI/FC) accessible to both nodes, and fencing (STONITH) in production.
• Pacemaker imports/exports the pool on the active node; the SMB/NFS services and the VIP are managed by the cluster.
• Transparent failover, zero RPO: when the active node fails, clients reconnect to the same virtual address.

Mode 2 — Replication ("Option A")#

• Each appliance keeps its own local pool; an asynchronous ZFS replication keeps the passive node as a read-only mirror.
• Local role = Primary or Secondary (mirror).
• Manual failover via the "Fail over (failover)" button; RPO = the replication interval.
• "HA Replication Assistant — Option A" wizard (2 steps: Peer & replication → Summary & risks), with two mandatory acknowledgements (RPO and split-brain). When creating a volume, the "Replicate to the HA peer" toggle includes it in the mirror. See the replication guide and the DR section above.

Setup#

Common prerequisites: two Caelum appliances of the same version and a shared hacluster password. From the High availability tab (System), follow the wizard for the chosen mode.

Updates, channels and rollback#

The two update channels: stable and beta#

Caelum offers two update channels, configurable in System → Updates / Rollback:

• Stable (recommended in production): only offers proven versions. This is the default channel.
• Beta (preview): offers release candidates early, to test what's new. Reserve for a test environment or a non-critical node. Enable the "Receive beta (preview) versions" checkbox.

The availability of a new version is shown according to the selected channel (Update → vX.Y.Z indicator).

Update#

From System → Updates / Rollback:

1. Check the available version.
2. Launch the update in one click (via the support account) — or install from a file for an air-gapped environment (a galilo-update-*.tar.gz tarball uploaded in the interface).
3. A pre-update snapshot is taken automatically before the operation.

The update does not touch your data; it updates the appliance's software.

Roll back#

If an update causes a problem, the pre-update snapshot lets you return to the previous state from the Updates / Rollback tab. You can also download an application backup (configuration, policies — without user data) for archival.

Security and routine maintenance#

• Hardening: the Security tab (System) provides a read-only audit (updates, ports, SSH, firewall…) and guided hardening actions (firewall, NFS port pinning) that preserve your SSH session.
• TLS certificate: replace the self-signed certificate with one from your authority, or generate a signing request (CSR) — the private key never leaves the appliance.
• Support bundle: in case of an incident, generate a support bundle (logs and system state, secrets masked) to send to support.
• S3 purge: objects whose retention has expired are purged automatically each night; a manual purge is also available (Maintenance tab).

Going further#

• Understand the concepts: product overview.
• Screen by screen: administration guide.
• Solve a problem: troubleshooting and FAQ.