Automatic updates (operators)

Go to the contents

bkp_updater updates the programs as soon as a new update lies on a server reachable over HTTPS. It is not a permanent service but a short program that a systemd timer or the Windows Task Scheduler starts daily. Without a configured url it does nothing.

23.1 Commands#

bkp_updater --status                # configuration, detected system, manifest number seen last
bkp_updater --check                 # load and check the manifest; exit 10 = there is an update for this system
bkp_updater --update                # check and install (the timer starts this); exit 75 = try again later
bkp_updater --update --dry-run      # only report
bkp_updater --rollback              # back to the previous version
bkp_updater --adopt /usr/local/bin  # take over an existing installation copied by hand

Further options: --config <file>, --url, --channel, --public-key, --ca-file, --proxy, --state-dir override the configuration; --fetch <dir> only downloads the package (size and SHA-256 are checked); --force tries a version noted as failed again; --to <version> chooses a certain version; --allow-downgrade allows a downgrade (only together with --to); --restart-now restarts bkp_target right after the update without waiting for running sessions.

23.2 Setting up#

Copy packaging/updater.conf.example to /etc/bkp/updater.conf (Windows: %ProgramData%\AegisGrid\updater.conf) and enter at least url and public_key:

# /etc/bkp/updater.conf
url = https://updates.example.com/aegisgrid
channel = alpha
public_key = lLUdSf+bz5nFZEHOddf3m4ROKcOdmmwTfLW+wnTXMfw=

# libraries a new version needs: auto (default) | system | bundled
dependencies = auto
allow_package_install = no

# after switching, restart the long-running server (bkp_target ends gently):
restart_command = systemctl restart bkp_target
# wait at most this long (seconds) for running sessions of bkp_target, 0 = at once:
#target_restart_wait = 1800

#ca_file = /etc/bkp/update-ca.pem
#proxy = http://proxy.example.com:3128
#install_dir = /opt/aegisgrid
#link_dir = /usr/local/bin
#state_dir = /var/lib/bkp_updater

Then check with bkp_updater --status and make a first dry run: bkp_updater --update --dry-run.

23.2.1 Linux: systemd timer#

cp packaging/systemd/bkp_updater.service packaging/systemd/bkp_updater.timer /etc/systemd/system/
systemctl daemon-reload
systemctl enable --now bkp_updater.timer
systemctl list-timers bkp_updater.timer

Excerpt: adapt the time to your own backup window

# bkp_updater.timer
[Timer]
OnCalendar=*-*-* 11:00:00
RandomizedDelaySec=2h
Persistent=true

The service unit sets SuccessExitStatus=75 so that a skipped run (another updater is running right now) does not count as an error. As an alternative to the timer there is packaging/cron/bkp_updater (/etc/cron.d/bkp_updater, daily at 11:17, output to /var/log/bkp_updater.log).

Directory structure after --adopt or the first update: the programs lie under /opt/aegisgrid/versions/<version>/, /opt/aegisgrid/current points to the active version and /usr/local/bin/bkp_* to current/bin/*. A file copied by hand into /usr/local/bin is never overwritten.

23.2.2 Windows: Task Scheduler#

bkp_updater.exe --install-task      # creates the task "AegisGrid updater"
bkp_updater.exe --remove-task       # removes it

The task runs daily as SYSTEM with a random offset of up to 1 h. The programs lie in <install_dir>\bin, every version additionally in versions\. Running .exe files are renamed and the new one copied; the running program finishes with the old file, which is deleted at the next run. If the job scheduler service has a job right now, it accepts no new one afterwards, lets the running ones finish and then starts with the new program.

23.3 What happens during a run#

1. For an installation activated with an activation code, renew the license if it is due (section “Trial version and license”).
2. Load and check manifest and signature.
3. Choose the package that matches the system.
4. If a backup, a restore, a maintenance or a job of the job scheduler is running right now, it is installed anyway: they finish with their previous version (Linux: their version directory stays until nothing runs from it any more; Windows: the running .exe is renamed). Only another updater makes the run skip (exit 75).
5. Load the package (size and SHA-256 from the signed manifest), unpack it into a staging directory.
6. Try every new program with --version and --selftest.
7. Switch atomically (Linux: symlink; Windows: rename the running .exe, copy the new one), run restart_command if set (first wait until no session runs on bkp_target any more, at most target_restart_wait). bkp_sched holds running backups, restarts as soon as its other jobs are finished, and continues the held backups afterwards.
8. Run the self-tests once more at the installation place and switch back automatically on an error.

The last two versions are kept. A version that failed here is not tried again until a newer one appears (--force forces it).

On Linux the updater also restarts bkp_sched.service and bkp_target.service after switching (without restart_command as a fallback), and an idle job scheduler is stopped for the duration of the update. This only applies to services whose program comes from the updater's own installation (install_dir, links resolved); services of another installation on the same machine stay untouched.

Before restarting bkp_target, the updater looks into the target's session list (the same one the target console shows under “Sessions”) and waits until no session runs any more, at most target_restart_wait seconds (default 30 minutes). The job scheduler is already running again during this time. When the time is up, it restarts anyway: bkp_target lets running sessions finish until drain-timeout and closes the rest in an orderly way; these backups continue after the restart as the same run. bkp_setup and bkp_updater --update --restart-now do not wait.

23.4 Which update for which system#

The manifest assigns every package a selection (match): operating system, architecture; for Linux distribution (also through ID_LIKE, Ubuntu counts for Debian entries), version (VERSION_ID, for example Debian 12, Ubuntu 22.04) and minimum glibc; for Windows the build range (Windows 10 = build 19041 to 21999, Windows 11 from 22000) and server/client. If there is no matching package for a system, this is not an error: simply nothing happens. A staged rollout (rollout_percent) offers a release only to part of the machines (stable per machine and version).

23.5 Missing libraries#

If something is still missing, the update is refused, the old version stays active and the message names the missing libraries and packages; the next run tries again. On Windows this does not apply: the programs are built statically and only need Windows' own DLLs.

23.6 Rollback#

bkp_updater --rollback

Switches back to the previous version (Linux: symlink, Windows: files from versions\). An automatic rollback already happens during the update if the self-tests at the installation place or the restart_command fail.

23.7 Activating the installation (bkp_license)#

The update server can restrict the update channels to activated installations. An activated installation has a certificate of its own that updater and setup send along when downloading. Without activation the updater then reports: “the update site serves this channel to activated installations only (HTTP 403)”. The installed version keeps running; backups and restores are not affected.

Activation is done with the activation code through the AegisGrid license server or, without a code or without an internet connection, through a request file and an answer file (both as root or administrator):

bkp_license activate                    # asks for the activation code
bkp_license activate --code-file code.txt

# by file:
bkp_license offline-request             # writes aegisgrid-anfrage-<machine>.json
# send the file to AegisGrid support, the answer file comes back
bkp_license offline-apply AegisGrid-freischaltung-<machine>.json
bkp_license status                      # shows activation, validity and license
bkp_license renew                       # renew license and certificate now (otherwise daily by itself)
bkp_license deactivate                  # give the place back (the uninstall does this itself)

Output:

Activation:       active, certificate valid until 2027-10-19
Installation:     I-00017
Customer account: A-000042
Roles:            agent, restore, sched
License:          no license file.
Hardware ID:      2cfbec4b-9865-8663-81a9-172b9108380a

• The request contains machine name, version, the installed components, a certificate request and the hardware ID only as checksums (no serial numbers or MAC addresses in plain text). Without root, parts of the hardware ID are missing; bkp_license then warns.
• The key is created on the machine and never leaves it. Storage: /var/lib/bkp_license (Windows: %ProgramData%\AegisGrid\license), readable only for root or SYSTEM and administrators.
• The certificate is valid for one year with an activation by file, for a trial version until one week after its end, for a purchased license as long as the subscription, at most one year. An installation activated with an activation code renews it itself at the daily renewal (section “Trial version and license”) as soon as it expires in less than 30 days. An installation activated by file makes a new request in good time for this; the previous activation stays valid until the new answer has been applied.
• bkp_license status ends with exit code 0 if the installation is activated and the certificate is valid, otherwise with 1.

23.8 Trial version and license#

A trial version is activated with the trial code, as described above. It runs for 30 days from activation, with all modules and with updates. After that it makes no new backups. Everything else goes on: restoring, checking, exporting and the maintenance of the stores. To keep backing up, buy a license: we convert the account of the trial version into a customer account, and every installation gets the purchased license at its next renewal, without a new code and without reinstalling. If you want to keep backing up sooner, call bkp_license renew afterwards.

A purchased license runs as a subscription (monthly or with a term of 1, 3 or 5 years) and comprises as many points as were bought, with all modules and with updates. It only stops backups once it has expired and the grace period of 14 days is over (section “Purchased license”). If it no longer matches the machine, the renewal fails or more points are used than were bought, there are only notes beforehand.

23.8.1 Daily renewal#

The license of a trial version is valid for 3 days at a time, a purchased one for 30 days; both are renewed daily at the AegisGrid license server (outgoing HTTPS, with the installation certificate). bkp_sched does this itself: one minute after its start, then daily, hourly after a failure. On machines without a scheduler bkp_updater --update renews before every update. By hand it works with bkp_license renew.

• If the renewal fails, the installation reports this at once (console, bkp_license status, log of every backup, mail of the scheduler), with the date from which new backups stop. If a later renewal succeeds, the note is gone again.
• Only when the license has not been renewed for 3 days (trial version) or for 30 days plus 14 days of grace (purchased) do new backups stop. After the next successful renewal they run again by themselves.
• If the license server refuses the renewal (e.g. because the trial version was ended or the subscription has expired), the message names its reason and whom to contact. Waiting does not help then.
• The output of the renewal by the scheduler is in renew.log in the license directory (/var/lib/bkp_license, Windows: %ProgramData%\AegisGrid\license).

23.8.2 Notes before the end#

Console and bkp_license status show during the whole trial period how long it still runs. From 7 days before the end this becomes a note that is also in the log of every backup. For a purchased license the same applies from 14 days before the end of a subscription if the end is fixed (a term that was not extended, or a cancelled monthly subscription); a monthly subscription extends itself without a note. The scheduler also sends mails if a mail server is set up ([mail] in bkp_sched.cfg or a job that mails failures). Every mail comes only once, also after a restart of the scheduler:

23.8.3 Points#

A trial version comprises 10 points, a purchased license as many as its subscriptions have together. The installation itself costs nothing; only a backup takes points. The programs only report what they back up; what this costs is set by the license server, which writes it into the license. Currently:

• Counting happens at the start of a backup, no matter whether the scheduler, the Task Scheduler, cron or a person starts it, and no matter what is backed up (drive, volume, LV, USB disk) and where to. A unit counts until its last backup is 7 days ago: a VM taken out of the plan frees its points a week later.
• A VM host costs nothing unless it backs itself up with bkp_agent. If bkp_agent runs in a VM, it counts as a machine; if the VM is backed up at the host, it counts as a VM.
• A backup must run as administrator (on Linux as root) so that it can be counted; without these rights it does not start and says so.
• If a backup of a trial version would take new units over the limit, it does not start. Units already counted and the other jobs keep running. An M365 job starts completely or not at all, so that never only part of the users is backed up.
• At the renewal the installation reports its usage to the license server. If all installations of the trial version together are over the limit, there is only a note; each installation only stops if it exceeds the limit on its own.
• With a purchased license the limit stops no backup. If more points are used than were bought, there is a note, and we charge the difference afterwards.

23.8.4 Public target#

A public target is run by AegisGrid for its customers. Whoever backs up there pays no points but the storage their backups take up on the target, per TB and day. What a TB day costs is in your contract, not in the program. A customer's own target on the other hand counts through its role (1 point, table above).

On the target, /etc/bkp/hosted.conf says which folders under the storage belong to which customer account. A folder counts with all its subfolders; folders must not overlap, an account may have several. Without this file a target is not a public one.

storage = /srv/backups
kunde1        A-000042
msd/kunde2    A-000043

• bkp_license renew (as root, daily by the scheduler or the updater) measures once a day what every folder takes up on the disks, that is after deduplication and compression, and reports it to the license server at the renewal. If the target was off on a day, the last measurement applies to it.
• The license server only takes over the measurements from a target whose account is registered as an operator of public targets. Otherwise bkp_license status says so in the line “Public target:”; then please tell AegisGrid sales.
• Billing is per month, three days after its end, in gigabyte days (1000 gigabyte days = 1 TB day).

On the target bkp_license status shows the last measurement:

Output:

Public target:    2 customers take 3.250 TB (measured on 2026-10-23 02:10). The license server has taken the
                  measurements up to 2026-10-23.

23.8.5 Releasing a target for other accounts#

Every account with a target of its own can release it to other accounts, for example an IT service provider to its customers. The customer accepts the release, their machines then set up the target as a destination by themselves. Every machine of the customer creates the API key itself; only its checksum travels through the license server. Per release there is a quota, hard (full backups are refused) or soft (only a note). The storage used is billed as for the public target in gigabyte days, namely through the partner chain of the account that owns the target.

Releases are offered and accepted in the customer portal (cloud.aegisgrid.de): the operator chooses their target, names the account ID of the customer (A-…), the quota and the mode; the customer or their partner accepts or declines there. In the portal both sides see state and usage, the operator changes the quota, ends a release or has its data deleted, and the customer cancels. For their own invoice to their customers the portal shows the operator per month how many gigabyte days every customer has taken up on their targets.

On the target a line public in /etc/bkp/hosted.conf registers it at the license server. Customer folders by hand are not needed for this:

storage = /srv/backups
public  = backup.example.com:9990
name    = Backup Example Ltd

• public is the address by which the customers' machines reach the target; name is what customers see (without it: the address). If certificate (certificate, default /etc/bkp/target.crt) or ACL (acl, default /etc/bkp/acl) differ, the paths also belong in the file.
• bkp_license sync (as root, hourly by the timer bkp_license-sync.timer, which the setup creates with the target, or by the scheduler) registers the target and fetches its releases. Per release it creates the folder hosted/<release> under the storage, writes the accesses of the customer machines to /etc/bkp/acl.hosted and the quotas to hosted/quota, and reloads bkp_target if something has changed. Please do not change either file by hand.
• Every machine of the customer backs up into a subfolder of its own of its release and may read all subfolders, so that a new machine can restore.
• With a hard quota the target measures the folder of the release anew before every backup and refuses it if it is full. A running run is not cancelled and may exceed the quota; the next one is refused.
• If a release is ended, the target accepts no more backups for it. The customer's machines can still list their backups and restore them, for example to bring them to another destination. The data stays and keeps counting until the target's side has it deleted; then the target deletes the folder at the next synchronization.
• The folder hosted under the storage belongs to the releases; no customer folder in hosted.conf may lie inside it.

bkp_license status shows the state in the line “Shares:”:

Output:

Shares:           Target T-000001: 2 shares with other accounts, 2 of them active.

23.8.6 Using a released target#

If another account has released a target to your account and the release has been accepted, every activated machine of the account sets it up as a sink by itself at the next synchronization (hourly by the scheduler, at once with bkp_license sync as administrator or root). This creates, next to bkp_agent.cfg (/etc/bkp, Windows %ProgramData%\AegisGrid):

• sinks.hosted.cfg with a line in [targets] and a section [sink:<name>] per release. The name comes from the name of the target (e.g. “Backup Example Ltd” becomes backup-example, with a counter if the name is already taken) and never changes afterwards. All programs read the file along with sinks.cfg; it is written anew at every synchronization and must not be changed by hand. Settings of your own belong in sinks.cfg (see below).
• keys/hosted-<release>.apikey, the own API key of this machine. Only its checksum goes to the license server.
• keys/hosted-<release>.key, the key with which this machine encrypts its backups on the target (AES-256-GCM). Keep this file in a safe place outside the machine: without it the backups there cannot be restored, and the operator of the target cannot read them. If it is missing, the synchronization creates no new key but reports it.
• ca/hosted-<release>.pem, the certificate of the target.

Every machine backs up into a subfolder of its own of the release (hosted/<release>/<installation ID>). A profile uses the target like any other sink:

[fileserver]
source = /dev/vg0/data
sinks  = local,backup-example

Only target, directory and API key are fixed. Encryption, key, checksum (hash), required and retention are up to the customer: a section of the same name in sinks.cfg sets them instead of the default (with encryption = none the key of the default is dropped too), and sinks of your own may use the target with a directory below that of the release and the API key of the release. The console writes both; by hand:

# sinks.cfg
[sink:backup-example]
encryption = none

[sink:example-long]
type       = target
target     = backup-example
target-dir = hosted/G-000007/I-0000042-example-long
api-key    = file:/etc/bkp/keys/hosted-G-000007.apikey
retention  = 1y

bkp_license status shows the released targets with quota and usage (state of the last synchronization, all machines of the account together):

Output:

Other targets:    'Backup Example Ltd' from Example IT Services as sink 'backup-example': takes 1.85 TB
                  of 2.00 TB (hard).

• The scheduler mails (to the address for errors) when a released target reaches 90 % of its quota, when it is full and when the release ends. With a hard quota the target refuses new backups as soon as it is full; restoring goes on. Room is made by deleting old backups (retention, bkp_maintenance prune) or by a bigger quota from the operator.
• If the release ends, the sink stays in sinks.hosted.cfg (so that profiles naming it stay readable), but backups there stop with a clear message until the profile gets another sink. Restoring goes on until the operator deletes the data; after that bkp_restore leaves the sink out with a note.

23.8.7 Distributing a target within your own account#

A target that only backs up for your own company does not have to be entered by hand on every machine. A line internal in /etc/bkp/hosted.conf registers it at the site server of the account, and every activated machine of the same account sets it up as a sink by itself at the next synchronization, just like a released target (own API key, own key, own subfolder). Other accounts get nothing of it. There is nothing to offer or accept, and nothing is billed. Whoever wants to keep the addresses of their own targets in their own network runs a site server of their own (chapter “Site server”).

storage  = /srv/backups
internal = nas.example.lan:9990
name     = Backup Head Office

• internal is the address by which your own machines reach the target in their network; name is the display name (without it: the address). public may be there as well if the target is also released to other accounts; a target with only internal cannot be offered to other accounts.
• There is no quota by default. If you want one, set it in the customer portal at the release “own account”, hard or soft, and you can remove it there again.
• The distribution is ended by removing the line internal from hosted.conf. After that the target accepts no more backups of your own machines; they stay readable until the data is deleted in the portal. If the line comes back while the data is still there, it goes on with the same backups.

On the target bkp_license status shows the registration, on the machines of the account the target is under “Own targets:”:

Output:

Shares:           Target T-500000003 registered, no accepted share with other accounts; for the machines
                  of the own account at nas.example.lan:9990.

Output:

Own targets:      'Backup Head Office' as sink 'backup-head-office': takes 640 GB, no quota.

23.8.8 Groups: a shared folder for several machines#

Without a group every machine backs up into its own subfolder of a release, with its own key; the same data of different machines then lies several times on the target. In a group the machines of a department or a site back up into the shared folder hosted/<release>/<group> with a shared group key; what they have in common (operating system, programs, templates) lies there only once. Groups exist per release, also for “own account”; a machine is in at most one group per release.

• Groups are created, renamed and deleted (only without members) by the customer side in the customer portal at the release; there is also a quota per group (hard or soft, in addition to that of the release) and a default group that new machines of the release join by themselves.
• Joining, changing and leaving works in the portal, in the management console (window “Release...” of a sink, area “Group”) or on the machine with bkp_license group join --grant G-… --group <name> or group leave. Joining only works if the backup names of the machine are free in the folder of the group (section “Backup names per store”, Chapter 6); otherwise the console names the name and suggests a free one.
• The first machine of the group creates the group key. The others get it sealed through the license or site server, each only for the checked certificate of the recipient; the server itself can never read it. Only once the key is confirmed does the sink back up into the group folder. The keys lie in keys/hosted-<release>-<group>.v<n>.key.
• The previous backups stay readable: when joining, the read-only sink <sink>-vorher is created with the old folder and the old key, when leaving, one for the folder of the group left. Restore and --list see both like any other sink.
• Group stores always use the ID hash blake3. Cleaning up (data no longer needed) only happens on the target: there the release creates the job gc-hosted-<release> (daily at 03:30), because a single machine cannot know what the others still need.

Emergency copy of the group key. If all machines of a group are lost, the key only exists in an emergency copy. It belongs in a safe place far from the machines of the group, sealed with a password. As long as there is no confirmed copy, the console shows a note, and the job scheduler mails if only this machine has the key.

Emergency copy and key change

bkp_license group-key export --grant G-000007 --to /media/usb/group-default.txt --password-file /root/password.txt
bkp_license group-key import --grant G-000007 --from /media/usb/group-default.txt --password-file /root/password.txt   # machine set up anew
bkp_license group-key rotate --grant G-000007                                                                         # new key

• In the console: “Save key...” in the area “Group” asks for password and file; the copy counts as made as soon as the server has noted it.
• A key change (“New key”, group-key rotate) applies to all machines of the group. New backups begin a new store generation with it; the older ones stay readable with the earlier keys (previous-keys= in the sink). Then save a new emergency copy.
• If a machine leaves, is taken out or has not been seen for a long time, the group automatically gets a new key version: the former machine can no longer read new backups of the group.

Taking older backups into the group. The backups from before joining are encrypted with the old key and therefore cannot simply be moved into the group folder. In the management console the window “Release...” of the sink <sink>-vorher shows the button “Move into the group...”: the job scheduler creates the job move-into-<sink> (a job by hand, without a schedule) and starts it. It reads every backup with the old key, encrypts it anew with the group key and writes it into the group folder; what is already there is not stored again. After that the backups can be restored from the group like new ones and count towards its retention. The old folder stays unchanged until the release removes it. This only works on Linux machines; by hand:

Older backups re-encrypted into the group

bkp_maintenance mirror --reencrypt --store sink:msp-vorher --to sink:msp --sink-store default,files

If old folders belong together that were written with the same key (or unencrypted), the operator of the target moves them without a key: in the target console “Data” › “Move...” or bkp_maintenance move (Chapter 10).

The window “Release...” shows the state of a group: members, usage of the group folder with quota and savings (“240 GB saved (38 %)”), key version and emergency copy. In the target console the group folders are in the tab “Releases”, indented below their release.

23.8.9 Looking at the state#

bkp_license status

Output:

Activation:       active, certificate valid until 2026-11-22
Installation:     I-00017
Customer account: A-000042
Roles:            agent, restore, sched
License:          Demo: the trial period runs until 2026-11-19 (30 days left).
Renewal:          last on 2026-10-20 09:14
Points:           This installation takes 4 of 10 points (1 server, 2 VMs, 3 M365 users). All
                  installations together: 6 (as of the last renewal). What has not been backed up
                  for 7 days no longer counts.
Hardware ID:      2cfbec4b-9865-8663-81a9-172b9108380a

The line “License:” shows the same sentence the backups, the console and the scheduler see: days left, notes or why new backups are stopped, each with the next step. If a backup was not started because of the points, the line “Not started:” follows with time and reason.

23.8.10 When new backups are stopped#

bkp_agent, bkp_m365, bkp_proxmox, bkp_xenV and bkp_hyperV ask the license before every backup, even before snapshot, checkpoint and freezing a VM. If new backups are stopped, they end at once with exit code 77 without changing anything. The scheduler records the run as “Not started (license)” (API: BLOCKED), not as an error, and only mails at the first run stopped like this in a row. Restoring, checking, exporting and maintenance never ask the license.

23.8.11 Purchased license#

• The license is valid for 30 days at a time and is renewed daily as long as the subscription runs. A monthly subscription extends itself every month until it is cancelled, and then runs until the end of the month. A subscription with a term (1, 3 or 5 years) ends at its end date unless it is extended beforehand.
• Further places, points, a new subscription or an extension are ordered from AegisGrid sales or from your partner; more points apply at once, fewer from the next month or the end of the term.
• When a subscription ends, the license server issues no more licenses afterwards. The installation keeps backing up until the end of its license, then for another 14 days of grace with a daily note, then it stops new backups. Restoring always works.
• If someone bought the license through a partner (IT service provider), bkp_license status (“Managed by:”) and all notes name this partner as the contact.
• There are updates as long as the installation certificate is valid. It runs with the subscription and is extended by itself at the renewal. If it has expired after a long break, activate the installation anew with its activation code; the license server recognizes the machine again.

bkp_license status

Output:

Activation:       active, certificate valid until 2026-12-12
Installation:     I-00017
Customer account: A-000042
Roles:            agent, restore, sched
License:          The license is valid until 2026-11-20 and is renewed automatically while the
                  subscription runs.
Managed by:       Example IT Services Ltd
Renewal:          last on 2026-10-21 09:14
Points:           This installation takes 4 of 25 points (1 server, 2 VMs, 3 M365 users). All
                  installations together: 18 (as of the last renewal). What has not been backed up
                  for 7 days no longer counts.
Hardware ID:      2cfbec4b-9865-8663-81a9-172b9108380a

If the end of the subscription is fixed, the line “License:” says “The subscription ends on …”, and the line “Subscription:” names the date.

23.8.12 Giving the place back#

Every activated installation takes a place of its activation code. An expiry of the license does not free it: the installation then only makes no new backups. The place only becomes free when the installation gives it back:

• Uninstalling (bkp_setup --uninstall, on Windows “Apps & features”) gives it back at the license server and reports that the license place of this installation (I-…) is free again. If the license server cannot be reached right now, the programs are removed anyway; the message then names the installation whose place stays taken until AegisGrid sales frees it.
• Without uninstalling, e.g. before changing machines: bkp_license deactivate (asks, --yes without asking).
• If a machine has failed and can no longer be uninstalled, AegisGrid sales frees the place (please name the installation ID from bkp_license status or the console). If the machine comes back onto the network after all, it learns about this at its next daily renewal.

After the place has been given back, no AegisGrid program works on the machine any more, not even a restore, until it is activated anew with an activation code (bkp_license activate or the setup). The programs end with exit code 77 and a sentence in the log, the scheduler stops, the console shows a message. A new activation needs a free place again.