Installing and configuring a BeBackup server

This guide covers the installation of a BeBackup server on Windows, its initial configuration and its move into production. It is intended for the hosting provider operating the server — not for the end user, and not for the installation of the backup agent, which is covered in a separate document.

---

1. Prerequisites

You will need bbServerInstall.exe and your licence key, both supplied by EDII with your licence (or your trial licence).

No hardware sizing is imposed. Deployments range from refurbished branded servers to custom-built machines, and both give satisfaction. Size according to the number of media and the volume to be retained, not according to a list of prerequisites.

On Windows 10 or 11, one reservation and one only: these versions are technically suitable — a production deployment on them handles several hundred media — but Windows 10 reached the end of Microsoft support in October 2025. A machine that listens on the Internet and holds your customers' backups should not be left without security patches: plan for an edition that is still maintained, or an extended updates contract.

---

2. Installation

Run bbServerInstall.exe as administrator and follow the wizard:

1. Acceptance of the licence agreement.
2. Installation location — C:\Program Files\BeBackup Server by default.
3. Firewall exception — leave the option ticked. The wizard adds an inbound rule authorising

the server executable.

1. Installation of the files, then of the Visual C++ redistributables.
2. At the end of the wizard, leave ticked the option that launches activation.

The wizard also registers the server's Windows service.

---

3. Licence activation

Activation is carried out by the bbActivation.exe utility, launched automatically at the end of installation (it remains accessible afterwards from the Start menu). It asks for:

• your licence key;
• your email address;
• the password that was provided to you.

What a licence covers

A BeBackup licence is not simply a number of workstations. It defines:

The licence types consumed by the backed-up machines:

The list of authorised addresses is part of the licence. If you later add a DNS name or a public address, the licence must be updated from the web interface (Licence tab), failing which agents connecting through that address will be rejected.

---

4. What the installation puts in place

4.1 Windows services

The last two are only installed and started when the corresponding feature is enabled: their absence on a fresh installation is normal.

4.2 Folders

Under the installation folder:

Customers' backup data is not stored here: it goes into the storage locations you declare (§ 6.5).

4.3 The three ways of running the server

Maintenance mode is not secure — that is its very purpose, and the server states this explicitly in its log at every startup. It exists to put the first configuration in place, when no administrator account yet exists. Never leave it running in production, and do not expose it to the network.

A "Configure BeBackup Server" shortcut opens the interface at https://localhost.

---

5. First startup

1. Check that the service is stopped (console and maintenance modes and the service cannot

listen on the same port simultaneously).

1. Launch the BeBackup maintenance shortcut. A console window opens: leave it running.
2. Open https://localhost in a browser.

At this stage the server presents a certificate that no authority recognises: the browser displays a warning, which must be accepted in order to continue. This is normal and temporary — configuring the certificates (§ 6.3) resolves it.

---

6. Configuration through the web interface

The server configuration page is organised into ten tabs:

General · Email · Security · Administrators · Storage · Linked servers · Licence · AI · Update · Advanced actions

The order below is not that of the interface: it is the one in which they are most simply handled during initial configuration.

6.1 General — the server's identity

The host names are the list of DNS names and IP addresses — local and public — by which an agent can reach this server. The agent tries them one after another and keeps the fastest route: a machine on the local network will use the internal address, a roaming machine the public address.

This list also feeds the names carried by the server certificate. If you modify it later, remember to regenerate or renew the certificate, and to update the licence.

6.2 Email — sending reports and alerts

The server sends backup reports to customers and monitoring alerts to the operator. Enter the settings of your outgoing mail server: host, port, authentication, TLS mode, sender name and address.

Also enter:

• the address that will receive the server's alerts;
• the level from which an alert is sent (at a minimum, critical messages);
• the subject of alert emails, and the repeat interval for a given alert.

Do this before creating the administrator accounts. A security option can require a code received by email to be entered when an unknown browser connects: if email sending does not work, that code never arrives. (Administrator accounts are exempt from it, precisely so that there is always a way in.)

6.3 Security — securing communications

Two approaches, to be chosen according to your context.

a. Public certificate obtained automatically (ACME)

The server is able to obtain and renew on its own a certificate from an ACME authority (Let's Encrypt or equivalent). A scheduled task periodically checks whether renewal is due.

You need to enter: activation, the provider or ACME directory URL, and the account's email address. Some authorities additionally require external account binding credentials (EAB), which are also catered for.

This is the simplest route when the server has a public DNS name and is reachable from the Internet. Agents and browsers then recognise the certificate without any further configuration.

b. Local certificate database

The server includes its own certification authority. The procedure:

1. Create a certificate database — this creates a root authority. Enter a name, a validity

period, the key size (4096 bits recommended) and the hash algorithm (SHA-2). You can protect the database with a password, which will then be requested each time a certificate is created.

1. Create a server certificate — its name must match the DNS name by which the server is

reached.

1. Assign it to the server.

Choose a long validity period for the authority: when it expires, every certificate it has signed must be reissued.

This route also allows client certificates to be issued to administrators (§ 6.4).

6.4 Administrators — interface access accounts

Create at least one administrator account before leaving maintenance mode.

For each account: a name, an email address and a password.

The client certificate is an additional protection: the interface is then accessible only to browsers presenting a certificate issued by your database. To use it:

1. Add a certificate to the account (3 years' validity and a 4096-bit key are reasonable values)

and tick the option that makes it mandatory for that account.

1. Download the .p12 file and import it into the certificate store of the administration

workstation. The password requested on import is the one entered when the certificate was created.

1. Then untick the general option "allow connections without a certificate".

Order of operations. Until you have imported and verified your client certificate, leave connections without a certificate allowed. Prohibiting them before you have a working certificate will lock you out of your own interface.

Other available security settings: account lockout after a number of failed login attempts, web session lifetime, and the email code for an unknown browser mentioned in § 6.2.

6.5 Storage — where the data goes

1. On each volume intended for backups, create a dedicated folder (for example D:\bbStorage —

fictitious example).

1. Declare one storage location per folder in the interface.

Declare as many storage locations as you have volumes: the server distributes the media between them.

Plan for free space monitoring: the server can raise an alert below a configurable threshold (§ 7.3).

6.6 Licence

This tab displays the licence status and allows it to be updated — an operation required after any change to the list of DNS names and addresses by which the server is reached.

6.7 Linked servers (optional)

If you operate several BeBackup servers, this tab establishes the link that enables replication of backups from one server to another and the synchronisation of common items. To be configured once both servers are installed and reachable.

6.8 Update

This tab drives the server update process (§ 7.2).

6.9 AI (optional)

The AI tab brings together the settings for artificial intelligence assistance. It only has an effect if this feature is enabled on your server; otherwise, leave it as it is.

6.10 Advanced actions

One tab brings together the fine-grained settings: backup behaviour, timeouts, monitoring, media defragmentation, replication, server language, accelerator. The default values are suitable for a standard installation — only change them for a specific reason.

---

7. Moving into production and day-to-day operation

7.1 Switching to service mode

Once the configuration is in place:

1. Close the maintenance mode window.
2. Start the service: net start bbServer (or via the services manager).
3. Reconnect to the interface — this time with authentication, and with your client certificate if

you have made it mandatory.

Check that the bbServerWatchdog service is also running: it is the component that restarts the server if it stops responding.

7.2 Server updates

The server periodically checks for a new version and can apply it on its own if automatic updating is enabled. The package is verified before installation: the package signature and the signature of each binary it contains are checked, and a version older than the one running is rejected. The restart is handled by the watchdog.

You can also trigger the check from the Update tab.

Back up the installation folder before a major update, in particular the internal databases (§ 7.4). That is the only way to roll back.

7.3 Monitoring

The server runs several periodic tasks on its own:

These alerts are sent by email to the address configured in § 6.2 — hence the importance of validating email sending from the outset.

7.4 Internal databases and their copies

The server keeps its own databases in the installation folder (configuration, accounts, media, backup indexes). It retains rotating copies of them in backups\ — five by default, the most recent carrying the -bak1 suffix.

These copies are your safety net in the event of a database problem. They are on the same volume as the server: include the installation folder in your own backup plan.

Restoring a database from a copy. The operation is rare but it does happen, in particular for a medium's index file (.fat), which sometimes has to be replaced by its copy (.fat-bak). The procedure is always the same:

1. Stop the server — a database replaced while the server holds it open would not be re-read,

and you would risk losing the copy as well as the original.

1. Set the original aside rather than overwriting it: rename it, do not delete it. If the copy

turns out to be older than expected, it is your only way back.

1. Copy the backup in place of the original, giving it its original name — for example

support.fat-bak becomes support.fat.

1. Restart the server and check in its log that the database opens correctly, then in the

interface that the medium and its versions appear as expected.

As the copies are numbered from the most recent to the oldest, move up one step at a time if the first one is not suitable.

---

8. Optional features

Each is configured in the interface and is left disabled until it is used.

---

9. First-level diagnostics

Where to look

Everything happens in logs\, under the installation folder. The logs are split by startup and by subsystem: each server startup creates a series of files, including a main log and specialised logs (requests, web interface, network, email sending, replication, remote control of agents, etc.).

The main log for a given startup has the shortest name in its series. Its first lines summarise the version, the licence, the authorised addresses and the listening port: it is the first place to read.

Common symptoms

Before calling support

Have ready: the server version, the main log of the startup concerned, and the exact time of the incident.

---

10. Getting help

Before opening a ticket, gather the server name and version, the date and time of the incident, and the logs for the startup concerned (§ 9): this is what saves the most time.