Settings

Settings is where you tune how Asternodis behaves, and where the things you configure or review occasionally live rather than the ones you work in daily. It is organised as tabs, ordered by how often they are actually opened:

Each tab is a real page with its own URL: General is /settings, and the others are /settings/users, /settings/hooks (Automation), /settings/compliance, /settings/license and /settings/audit, so you can link or bookmark one directly, and it appears on its own in the sidebar search. The older top-level addresses (/compliance, /license, and so on) still resolve, so existing links and bookmarks keep working.

Within the General tab, a table of contents (a sticky rail on wide screens, a Jump to… menu on narrow ones) lets you jump between sections.

General is admin-only, as are Users & access, Automation and the Audit log. Compliance and License are readable by any signed-in role: the people who need DR evidence or need to check an entitlement are often not administrators.

Software updates

Shows the installed build and the latest published release, with Check now and a one-click Update that downloads the signed release, verifies its Ed25519 signature (a release that doesn’t verify is refused), and restarts the service, the same thing the update.sh script does. See Updating & rollback.

Dual control for failover

One switch, Enable dual control: while it is on, a single-guest failover and a recovery-plan failover become requests that a different operator must approve (DR tests, failback and abort are unaffected). See Users & security.

Self-healing

On by default. Replication recovers on its own from the leftovers of an interrupted cycle, such as a stale backup job, a leaked target block device, or an inconsistent change-tracking bitmap (rebuilt with a reseed), instead of letting the run fail. Every recovery is written to the audit log. Turn it off to have such faults surface as failed runs for manual handling.

Automatic guest-agent install

On by default. When a DR test or failover boots a recovery copy from a crash-consistent point (the sign that the guest agent wasn’t running to quiesce it at capture time), Asternodis installs the guest agent into that copy before it boots, for both Linux and Windows guests, with nothing for you to do, so the guest comes back up with a working agent instead of none at all (health checks, IP detection, re-IP, and future application-consistent points all depend on it). The copy is edited offline while it’s still stopped, with no guest credentials needed and production never touched; a later failback carries the installed agent home with the rest of the disk. It’s best-effort (it never fails a recovery on its own account), and the run’s log says what it did.

On a Linux copy the agent comes from the guest’s own package repositories, so the recovery node needs a route to them. Windows has no package manager, so the installer and the small first-boot helper it needs to run unattended ship inside Asternodis; a Windows guest tools panel in Settings shows which files a recovery on this site will use and lets you stage your own in their place. To turn the automatic install off and leave recovered copies exactly as captured, see Don’t install the guest agent into recovered copies under Experimental features below.

Operator defaults

Set the defaults new work inherits: target RPO, recovery storage, whether recovered guests power on, and the console session timeout.

Leaving power on off is supported and sometimes what you want (a copy you mean to inspect before trusting, for instance). Know what it costs on the way home: a DR copy that is not running has nothing tracking its changed blocks, so its failback reads and compares the whole disk instead of shipping a tracked delta. Nothing is lost either way; only the time it takes to come home changes.

Replication limits

Bound replication with bandwidth caps, blackout windows, and concurrency limits so DR traffic doesn’t crowd production.

Recovery-point integrity reads sets how fast this site’s background integrity scrub may read the recovery copies it holds: one site-wide rate in MiB/s, with an optional override per storage. The reads are capped so they can’t crowd out failed-over guests on the same storage. Raise the rate if the Overview’s scrub cycle stays above 24 hours or it reports digest checks held back (a check that can’t finish between two captures is not started); lower it if the reads compete with guests. Admin only; local to this site and not synced. Set it on the site that holds the copies.

Replication data ports

The TCP range this site’s nodes listen on for VM disk replication (10800–20000 by default), one port per disk being seeded, failed back or restored at that moment. The other site’s firewall has to allow it in: the recovery site’s range is what the primary’s nodes dial to replicate, and the primary’s range is what the recovery nodes dial to fail back or restore, so each site sets, and opens, its own. It is local to the site and never synced; narrowing it tears nothing down, a range too small for the exports the site’s nodes already serve (plus sixteen spare) is refused, and one that overlaps the ports a node hands to outgoing connections is accepted with a warning. Data addresses, beneath it, lets you give a node the address the other site should dial for it (for a NAT, a separate replication network or a cluster address that isn’t routed between the sites), without changing how this controller itself reaches the node. A pair’s Network check (see Site Pairs) proves whether the two sites can reach each other on these ports.

Sync settings with paired sites

Optionally mirror settings to your paired sites so both ends of a pair stay consistent, and pull the latest on reconnect. Push settings now sends the bundle immediately; the card then keeps a line across reloads giving the time of that push and how many paired sites took it, so you can tell when the sites were last brought into line.

What crosses: operator defaults, anomaly detection, retention and alerting. What does not: users and roles, the license, remotes, automation hooks, per-pair recovery config, and dual control.

Dual control is per-site on purpose. It is a security control, and the settings bundle is authenticated by the pair secret with a revision the sender chooses; if it travelled, one site could silently switch off the other’s two-person approval gate, after which a single operator could drive an unapproved failover from across the link. So turning dual control on at your primary does not gate failovers driven from the recovery site. Turn it on at each site you want gated.

Controller backup & restore

Back up the controller’s configuration (its database and keys) and restore it from the UI, so a lost controller is quickly rebuildable. You can also do this from the CLI. If a restore doesn’t fully apply, Asternodis says so.

Topology

How this site takes part in DR across its pairs: Single pair, Hub (DRaaS), where many source sites recover into this one, Mesh, where the site is both a source and a recovery target, or Fan-out, one source replicating to several recovery sites.

This is a declaration, not a switch. Choosing a shape does not change how replication runs; the real topology is whatever pairs you have created. The card shows that live shape underneath (how many active pairs this site is the source in, and how many it is the recovery target in), so a declaration that has drifted from reality is visible instead of assumed.

The setting is local to this site and never synced: a hub and its spokes are deliberately different, and pushing one site’s answer to the other would be wrong.

Recovery placement

The recovery-cluster node failover and DR-test guests land on when a guest has no per-guest pin. See Recovery placement & networking.

Recovery-point retention

Control how long recovery points are kept. Asternodis prunes them automatically on a grandfather-father-son (GFS) schedule (keep the last N hourly, daily, and weekly points), so history stays useful without growing without bound. Manually captured points are always kept, and turning retention off keeps everything. The policy is instance-wide and synced across the pair.

Application-consistent points is on by default. Each capture quiesces the guest first: a VM through its guest agent (a filesystem freeze, or VSS on Windows), a container by pausing it with the host’s cgroup freezer for the moment its snapshot is taken. That way a database or mail server recovers cleanly rather than merely crash-consistent. A capture holds the guest’s writes only while its disks’ backup jobs start, usually a second or two, and releases it after at most 15 seconds (8 on a Windows guest); past that the point is recorded crash-consistent, with the reason on its badge. A guest that can’t be quiesced (no responsive agent, a container a backup holds, a stopped guest) falls back to crash-consistent on its own. Opt a single guest out, or force it on, with Recovery-point consistency on that guest’s page. A site that was capturing crash-consistent points under the old default gets a 24-hour notice (an advisory alert and a banner here, with Keep off and Turn on now) before the new default takes effect.

Web console URL

Advertise the address peers should use to deep-link back to this console: the address an operator would type, not an internal one. Leave it blank to fall back to the -web-advertise startup flag; a value saved here wins over that flag. It is set here, not in the first-run wizard.

Other policies

A signpost to the policies configured next to the feature they govern: the ransomware guard’s anomaly policy and alerting webhooks on the Replication page header, automation webhooks on Automation, and accounts on Users.

Experimental features

Opt into capabilities that are built but still being validated on production hardware, from a dedicated, clearly-labeled section. Each is local to this site (not synced across a pair) and off by default unless noted:

• Native ZFS send/receive: for ZFS-to-ZFS pairs, replicate with zfs send | recv instead of the universal dirty-bitmap engine. Enable it on both sites of the pair.
• Force full reverse re-seed (disable the fast delta-only failback): note the inverted sense. The fast reverse baseline is on by default, and this switch turns it off. Normally, after a planned failover, Asternodis skips the full whole-disk re-seed on the first reverse cycle: it quiesces the source at fence time so the recovery copy is exact, then establishes the reverse baseline with a small incremental, and lets forward protection resume incrementally after failback too. It always falls back to a full seed on any doubt, and never applies to an unplanned (down-primary) failover. Applies when the recovery replica is a native volume (ZFS, LVM-thin or Ceph/RBD), not when it is a qcow2 file on directory, NFS or CIFS storage. Turn this on only as an escape hatch, for example while diagnosing a failback.
• In-place failback for non-ZFS home disks: on by default. It lets the reverse lane, and therefore in-place failback, write guests whose home disk is on LVM-thin, Ceph/RBD or a file storage (directory, NFS or CIFS), and VMs on thick LVM (including LVM on an iSCSI LUN) instead of ZFS. Each backing gets the same rollback net by a different route: LVM-thin promotes a thin snapshot, thick LVM takes a full-size copy-on-write snapshot and copies it back, Ceph/RBD uses an idempotent object copy, and a file home is written through a qcow2 overlay, so the production file is never touched until the failback is finalised, and rolling back is just discarding the overlay. It stays a switch, and stays labelled Experimental, because it lets the reverse lane write a class of production disk it has less field time on than ZFS. Two shapes are refused whatever the switch says: a thick volume group shared across the cluster (shared 1: LVM over a SAN or FC/iSCSI LUN every node sees) and Ceph/RBD configured with krbd or a namespace; those guests come home via Abort failover. Set it on the source (primary) site: the site whose disk the failback writes; the recovery site’s copy of the switch has no effect on it. Turn it off and every guest on these backings still fails over normally and comes home via Abort failover; a failback is refused up front with a message naming the site to change. Once the reverse sync has started writing a guest’s home disk, Abort failover is no longer offered for it, as for ZFS.
• Whole-disk failback verify: a belt-and-braces companion to Fast reverse baseline. With it off (the default), a fast-baseline failback trusts its change-tracking and verifies only the ranges it shipped, which is near-instant. Turn it on to additionally re-read the whole disk on both sides and compare byte-for-byte before trusting the copy, at the cost of a few minutes of local reads. Either way, any mismatch falls back to a full re-seed.
• Don’t install the guest agent into recovered copies: the inverted sense again. See Automatic guest-agent install above, which is on by default; this switch turns it off, leaving a recovered copy exactly as captured. Set it on the recovery site: it’s that site’s copy being edited.
• Don’t run the extended pre-boot repairs on recovered copies: the inverted sense once more. Beyond the ext4 and XFS fsck, the GRUB reinstall and the guest-agent install, a recovery also checks a copy’s FAT, NTFS, btrfs and LVM filesystems and repairs what has a safe offline repair: the EFI system partition, a Windows NTFS volume (replayed and marked so Windows runs its own chkdsk at first boot: expect a “Scanning and repairing drive” pass before the desktop), an XFS log holding unreplayed transactions, the filesystems inside the guest’s own LVM volumes, and, for a UEFI guest whose boot entries did not travel with it, the guest’s own EFI boot files. This is on by default; the switch turns it off so a recovery does only what it did before these existed. The read-only checks, the verdicts and the background scrub are unaffected. Set it on the recovery site: it’s that site’s copy being edited.

Continue to the CLI reference for host-side tasks.