Setting up backup

Before you protect anything, check three things in backup settings: where backups are stored, that you hold a recovery copy of the encryption key, and (for Microsoft 365) that the app registration is in place.

Open Settings > Backup (it is in the Backup group on the Settings home, and the search there finds any backup setting by name), or press Backup settings at the bottom of the Backup sidebar. The page has these tabs: Storage, Protection, Restores, Reports, Alerts, Defaults, Recovery, Microsoft 365, Self-service and Status.

Storage#

The Storage tab lists your storage locations: where repositories live. Each shows its kind, where it points, whether it has Object Lock, how many repositories and second copies it holds, how much is stored and, for a folder, the free disk space with a forecast of when it fills. Until one location is immutable, a note at the top says so and what to do. New repositories go to the Primary location.

A location is either a Folder on the backup server (an absolute path the backup service can write to, on a disk with room to grow) or an S3 bucket on AWS or other S3-compatible object storage.

To add one:

1. Press Add location and enter a Name.
2. Choose the Kind.
3. For a folder, enter the Folder on the backup server. For an S3 bucket, enter the Endpoint (host and port, without https://), Bucket, Region, an optional Prefix, the Access key and Secret key, and leave Use HTTPS and Check the certificate on unless your storage needs otherwise.
4. Press Check to test it, then Add location.

Secret keys are stored encrypted and never shown again. To make the new location the one new repositories use, choose Make primary. Existing repositories stay where they are, and every repository stays copied: see Second copies and the copy list.

You can lock an S3 location with Object Lock and copy every repository to a second location: see Storage locations and immutable backups.

Warning: Changing where a location points does not move the repositories on it. Copy them to the new place yourself first, or their recovery points cannot be restored. Tenvara asks you to confirm this before it saves.

Storage checks#

Every 15 minutes Tenvara writes, reads and deletes a probe in your storage, and for a folder checks the free space. Each check also times how fast the location lists its contents, shown on the card as "Lists in 120 ms": amber from 5 seconds, red when a list does not come back. Slow listing never fails the check or raises an alert, but it does slow every backup that uses the location.

If reads from a location keep failing (the storage answers with errors, or not at all), the location shows Reads failing, with since when, how many reads and the last error. It clears once those reads work again, or after a day of good reads.

On an S3 bucket with versioning, every deleted object leaves a delete marker, and thousands of them make the bucket slow to list. Tenvara adds a lifecycle rule to the bucket that removes expired delete markers, beside your own rules. If its key may not change the bucket's rules, the location's card says so and gives you the rule to add yourself, with a copy button. Delete markers only go once the versions under them have expired, so keep a rule of your own that expires old versions too: the card notes it when there is none. If storage cannot be written, or a folder has less than 10% free (Storage is nearly full below on the Defaults tab), it raises a storage alert. Check on a location runs the test now. A first Microsoft 365 backup of a tenant also needs room: on folder storage it only starts with 15% free, and stops taking on more below 8%.

The encryption key#

Every backup is encrypted with a master key that Tenvara creates the first time the backup service starts. On your own server it is held in a file called keys.json in the backup service's data folder.

On the Status tab, Encryption key shows:

• Fingerprint: a short code that identifies the key, with a button to copy it.
• Created: when the key was made.
• Repositories it protects.
• Last recovery copy and Recovery copy last checked: when a copy was last downloaded and last proved to open, and by whom.
• Approval: whether another administrator approves each copy.

Warning: If the key is lost, no backup can ever be restored, and it cannot be made again. Press Download a recovery copy to get the key sealed with a passphrase you choose, keep it away from the backup server, and use Check my copy to prove it opens. See A recovery copy of the encryption key.

On your own server the card shows a red warning, "Keep a copy of keys.json somewhere safe", until a recovery copy of the key in use has been downloaded and checked once.

The backup service refuses to start if repositories exist but the key is missing or does not match the fingerprint, rather than quietly making a new key. If that happens, put the key back from your recovery copy.

The catalogue#

Catalogue on the same tab is about the list of what each backup holds, which is what browsing and search read. Every backup carries its own catalogue, so the list never depends on one server. If a backup server is lost, install a new one with the same storage and the old key, connect the tenants, then press Bring back from storage: each repository's catalogue is rebuilt and it can be browsed and searched again.

The backup helper#

The Backup helper table on Status lists the helper builds for each platform: Windows and Linux (x64 and ARM) and macOS (ARM and x64), with their version, size and checksum.

• The agent downloads the right build when a device is protected, and updates it when a newer one is here. The helper waits until it is idle before it updates.
• A platform marked Missing has no build on this server. Devices on that platform show backup as not supported until one is added.

Removed devices on this tab lists devices that were deleted or retired whose backups are kept (see Protecting devices), and Service at the bottom shows the backup service version, the kind of storage and the address agents use to reach it.

Maintenance and verification#

Nothing needs setting up for repository upkeep, but it helps to know it runs:

• Quick maintenance runs at least daily in each repository's own window, when none of its backups are running. Full maintenance, which applies retention, runs weekly in the repository's quiet hours: the four hours its own backups were least busy over the last two weeks.
• Pack verification reads a sample of every repository's stored data back every week and all of it every month, and checks each piece. Set it on the Protection tab under Pack verification.

Both show on a repository's panel in Backup > Repositories. See Repository health, healing and verification.

Backup emails#

The Reports tab sets the emails backup sends:

• Customer backup emails: How often (Every day or Every week), the day and time, and Only when something failed to leave the email out when every backup went well. Each customer chooses who gets it on its Backup tab, under Customer reports, and can have its own schedule.
• Morning summary: one email a day to each of your people who turned on "Morning backup summary" in their notifications, with every backup failure and overdue item across your customers. Set the time, and whether it is sent when nothing is wrong. Send the morning summary to me now sends a test.

Microsoft 365 app registration#

Microsoft 365 backup and the rest of the Cloud area share one app registration, so customers only consent once. The Microsoft 365 tab explains this and has Open Microsoft 365 settings, which opens Settings > Microsoft 365 where it is normally set up and changed. You register the app in your own Microsoft Entra ID: nothing works for a tenant until that is done and the customer's administrator has consented.

If you set it up here:

1. In the Entra admin centre, open App registrations and create a new one. Choose Accounts in any organisational directory.
2. Copy the Redirect URI shown on this tab and add it as a Web redirect URI.
3. Under API permissions, add the Microsoft Graph application permissions listed under Permissions to grant.
4. Under Certificates and secrets, create a client secret.
5. Enter the Application (client) id and Client secret here and press Save.

The permissions the app needs are:

The tab lists the same permissions under Permissions to grant, so check there for the list your install asks for.

Note: Teams channel messages use a protected Microsoft API. Request access for your app at aka.ms/teamsgraph/requestaccess. Until Microsoft approves it, everything else backs up and Teams shows as failed.

Then connect each customer's tenant: see Microsoft 365 backup.

Checklist#

• Storage chosen and Check passes.
• A second location in the copy list, so every repository has a second copy.
• A recovery copy of the encryption key downloaded, checked with Check my copy and stored away from the server.
• Helper builds present for the platforms you support.
• Defaults set for schedule and retention.
• Customer backup emails and the morning summary set on Reports.
• Microsoft 365 app registration saved, if you back up Microsoft 365.