◍Operations and backups

The inside view of your system: database, background service, disk space, age of the last backup — with plain-language interpretation instead of bare numbers.

The traffic lights are called “fine”, “keep an eye on it”, “act now”; the banner at the top sums things up. The page checks itself every sixty seconds, and “Check again” works at any time.

On the overview, this is summarised in the “System” tile — seven checks, one dot.

Enlarge

No, and that is an important caveat. This page checks from the inside. Whether the instance can be reached from the outside is something it fundamentally cannot tell.

The reason is simple: a status page that only runs as long as the system is running never reports a total outage. For reachability from the outside, you need a second observer that is not on the same server.

If users report that nothing works and the status page is green, both can be true at the same time.

The age of the last backup is one of the seven checks in the system status. If it switches to “keep an eye on it” or “act now”, the last backup is too old.

Take this seriously, even if everything else is running: a missing backup is only noticed at the moment you need it. And a backup that has never been restored is an assumption — the restore test is part of it.

The database, the environment files and all uploaded files — attachments, candidate documents, one-pager images.

How long the backups are kept and when they run depends on your operating contract; on a managed instance, the backup runs nightly.

What is not backed up is anything that exists only in the browser — for example a half-written text that has not yet been saved.

Often yes — but not by you alone, and time is working against you.

Report it as early as possible and as precisely as possible: what is missing, since when, and when it was last definitely there. These three details determine which backup has to be restored.

In the meantime, avoid continuing to work in the affected area: a restore resets the state to an earlier point in time, and everything created after that has to be rescued by hand.

From your master data under Legal. From it, Aurora Hive Sales generates the legal notice (Impressum), the privacy notice, the data processing agreement (AVV) and the annex on technical measures.

Two properties matter more than the convenience:

• Whatever you leave open stays visibly empty — nothing is invented. Invented company details in a legal notice are noticed by nobody until it is too late.
• The list of services used is derived from the actual configuration of this instance, not from a fixed template. Whatever is listed there really is switched on.

No. They are drafts, not legal advice. Have them checked before the first customer contract — the data processing agreement first: your customer’s data protection officer will ask for it in the first meeting, and it has the longest lead time.

The benefit is not replacing the solicitor, but giving them a complete version that matches your actual configuration instead of a template from the internet.

Mandatory are:

• Company name — exactly as in the commercial register, including the legal form.
• Address — one at which legal documents can be served. A PO box is not sufficient under § 5 DDG (German Digital Services Act).
• Authorised representative — who represents the company externally.
• Email — must be in the legal notice and must be reachable.

In addition, where applicable: register and number, the VAT identification number (only the VAT ID under § 27a UStG, not the tax number) and the data protection officer — mandatory from 20 people who constantly process personal data.

Enlarge

It shows the state of the environments, the backups and the promotion of changes — for administrators only. Actions run directly on the server; the output is shown live as they run.

The route to deployment is fixed: commit and push, then promotion to the test environment, and only after that to live. Every deployment makes a backup beforehand, checks the health and rolls back by itself in case of errors.

Two groups, and both are marked:

• Red buttons need two clicks. Dangerous actions ask “Sure? Click again”. That is not an error; it is the last exit.
• Copying real data overwrites. “Live → DEV” and “Live → ABNA” copy real data into the respective environment — and overwrite everything there. Whatever test states were there are gone afterwards.

While an action is running, all buttons are locked. Wait for it to finish instead of reloading.

Instead of the application, the instance shows a maintenance page. That is the right state for a deployment in which users would otherwise run into half-updated states.

A tip from practice that saves time: after maintenance has ended, a browser may still have the maintenance page in its cache and then report strange errors. A hard reload with Ctrl+Shift+R clears that up.

There are three places where the space usually goes:

1. Attachments from connected mailboxes. A mailbox with stored attachments can easily take up several gigabytes — the tick box can be switched off.
2. Uploaded files for candidates and attachments. Clear out archived and definitely superfluous items.
3. Backups, if they are on the same disk. That is a matter for the operator, not for you.

Do not wait until the traffic light shows “act now”: a full disk does not just disable one function.

First check the effect, not the display: are campaigns running? Are replies coming in? If so, it is cosmetic.

There is one known case of this kind: if the inbox is switched off for an instance, the associated service does not report in and is therefore listed as unhealthy, even though it has nothing to do and nothing is missing.

If, on the other hand, campaigns stall and the bar does not move for hours, it is real and a case for the operator.

Yourself: everything to do with your own mailbox (password, permission), filters and views, stuck browser states, pausing and resuming campaigns.

Report: everything that concerns the system status — disk space, backups, background services — as well as any error that occurs reproducibly.

The borderline case is deliverability: the DNS entries are set by your domain provider, not by the operator of the instance. Aurora Hive Sales only tells you what is missing.

What you can see is the age of the last backup in the system status. Whether it can be restored cannot be seen from that — that requires a restore test, and it is part of operating your instance.

Ask about it. A backup that has never been restored is an assumption — and asking when it was last tested is a fair and usual question.

• Development — this is where things are built. The data is test data.
• Acceptance — this is where things are checked before they go into production.
• Production — your real system.

They look the same and have separate data and separate accounts. That is why the address bar tells you more than the screen content.

The route always goes in one direction: commit and push, then acceptance, and only after that production. And data copies run the other way — from production downwards, overwriting the target completely.