Schedules and retention

Every backup follows a schedule (when it runs) and a retention policy (which recovery points are kept). You set sensible defaults once, and override them only where a customer, device or tenant needs something different.

How settings are layered#

Tenvara looks for a setting in this order and uses the first it finds:

1. The device or tenant itself.
2. The device's site, when the site has its own schedule or retention.
3. The customer.
4. The defaults in backup settings.

Each place says where its value comes from, for example "Follows the default: Daily at 22:00", so you can always tell whether something has been overridden.

The defaults#

Open Settings > Backup and choose the Defaults tab.

Devices#

Schedule:

1. Set Starts at, for example 22:00. This is in each device's own time zone, so a laptop in another country still backs up at night locally.
2. Choose How often: Once a day, or every 12, 8, 6, 4 or 2 hours, or every hour.
3. Choose On these days. Untick weekend days for machines that are switched off.

The line underneath sums it up, for example "Daily at 22:00."

Retention keeps the newest recovery point for each period:

• Daily: the newest each day, for this many days (default 14).
• Weekly: the newest each week, for this many weeks (default 8).
• Monthly: the newest each month, for this many months (default 12).

The sentence below works out how far back that reaches. The newest recovery point of each volume or folder is never removed, however old it is.

Overdue after: how many hours without a good backup before a protected device is overdue and raises an alert (default 48).

To stop a customer's devices all starting at the same time and sharing one internet line, turn on Spread backups automatically: Tenvara then plans each night's start times per site under an upload budget. Spread backups automatically on this tab is the setting new customers start with. See Spreading backups across the night.

When many devices are due at the same moment, for example after the backup service has been stopped, they do not all start together. Device backups at once, under Thresholds and lifetimes on the same tab, sets how many run at a time; the rest wait their turn, longest overdue first. Leave it at 0 to have it picked from the backup server's processors and memory.

Microsoft 365#

Back up: how often each tenant runs, from every hour to once a day (default every 12 hours). With your own uplink window on (Settings > Backup, the Protection tab), tenants whose backups are kept on offsite storage start their scheduled runs inside that window; a tenant is not counted overdue for the hours the window is shut. Only changes since the last run are fetched, so frequent runs stay small. Tenants are spread evenly across the interval so they do not all start at once, and each tenant keeps its own time in the schedule. A new tenant's first full backup runs from the first backups queue, in slots of its own, so it never holds up the scheduled backups of tenants already backed up.

Retention, choose one:

• Keep every recovery point: every run can be restored, up to the age limit. This is the usual choice for Microsoft 365.
• Thin out older ones: keep fewer as they age: hourly, then daily, then weekly, then yearly.

Nothing older than (years) sets the age limit (default 7). Leave it empty to keep recovery points for ever.

Overdue after: how many hours without a good backup before a protected user, site or team is overdue (default 24).

Press Save defaults when you are done.

Per customer#

On a customer, open the Backup tab. Schedule and retention, below the recent jobs, shows what the customer's devices and Microsoft 365 use, where new backups are kept, what devices leave out and what happens to new devices, and whether each is the default.

To change them:

1. Press Change.
2. Under Devices or Microsoft 365, turn on Set here beside Schedule or Retention.
3. Set the values. They work the same as the defaults.
4. Press Save.

Devices and tenants with their own settings keep them. Anything not set here follows the defaults.

Per site#

A site can have its own device schedule and retention, between its customer's and each device's own. Set it from the site's Policies tab, where every module's settings for that site are shown together. See Policies and where settings come from. A site retention that keeps less than now waits for a second administrator, as a customer's does.

Per device#

On the device's Overview tab, press Settings in its Backup section and turn on Set here under Schedule or Retention. The device's schedule runs in its own time zone, which is shown with the setting. See Protecting devices.

Per tenant#

In Backup > Microsoft 365, open the tenant, then open ... and choose Schedule, retention and sign-in. Turn on Set here for the schedule or retention. See Microsoft 365 backup.

Keeping backups longer#

Retention is the rule; sometimes you need an exception: a leaver whose mail must be kept for seven years, a server before a big upgrade, an audit or a legal matter.

Keep longer#

On a device's Backup section press Keep longer.... On a Microsoft 365 person, site or team, or a Google Workspace item, use the same action on its backup.

1. Choose For a number of years and enter the Years, or For ever.
2. Enter Why. It is shown beside the backups for whoever looks next.
3. Save.

Every recovery point younger than that is kept whatever retention says; older ones follow the usual retention. Keeping for longer is a normal manage action. Keeping for less time than now, or removing the rule, is an administrator's and waits for a second administrator. A leaver can set the rule for you.

Pinning a recovery point#

To keep one particular backup, hover it in the device's Recovery points (or a Microsoft 365 item's) and choose Pin this recovery point, with a reason. A pinned point is never removed by retention and cannot be deleted until an administrator unpins it.

Backup > Pinned restore points lists every pinned point with its device or item, customer, what it is, when it was taken, its size and why it was pinned. Click one for a side panel with who pinned it, Restore from this point and Unpin.

How retention is applied#

Retention runs on the backup server as part of repository maintenance, never while a backup of that repository is running. Pinned points, points kept by a keep-longer rule and points under a legal hold are always kept, and partial points left by an interrupted backup are never counted:

• Quick maintenance runs at least daily for each repository, whenever none of its own backups are running. Full maintenance runs weekly in the repository's quiet hours (the four hours its own backups were least busy over the last two weeks). A new repository waits a day before its first, and its full maintenance waits until its first backup has finished.
• Retention removes the recovery points the policy no longer keeps, then frees the space they used.
• Maintenance shows in the Jobs list as Maintenance, so you can see when it ran and how long it took.
• When a repository is busy with a long backup, maintenance waits and tries again half an hour later instead of failing, and the repository's panel in Backup > Repositories says what it is waiting for. Quick maintenance and Microsoft 365 retention also run beside a long backup.
• When full maintenance is a week overdue and a backup keeps the repository busy, the backup pauses between its parts for it, at most once in six hours, and its job says "Waiting for repository maintenance". Full maintenance before a backup is time-boxed to two hours; if it runs out, the backup goes ahead and full maintenance waits for the next quiet hours.
• A running maintenance job shows its step and counts ("Compacting the index: 1,200 of 24,280 index blobs"). Cancel on its job stops it within a minute; the steps already finished are kept and the repository stays consistent. A maintenance job with no progress for 30 minutes is stopped by itself.
• A repository with no full maintenance for a week shows Maintenance overdue, and one alert for the install names every repository that has fallen behind. See Repository health, healing and verification.

Note: Deduplication means removing one recovery point rarely frees much space on its own: most of its data is shared with the points either side. Space comes back gradually as older data is no longer referenced by any point.

Choosing sensible values#

• Servers: daily is usually right, with a local copy for large file servers. Add a midday run (every 12 hours) where losing half a day's work would hurt.
• Laptops: daily at a time they are likely to be on, such as lunchtime, because a laptop that is shut at 22:00 cannot back up then.
• Microsoft 365: the default of every 12 hours and every point for 7 years suits most customers. Customers with regulatory requirements may need longer: leave Nothing older than empty to keep everything.