A hosted backup dashboard can tell you whether every machine in your fleet backed up last night without ever receiving a single file name, log line or error message from those machines. That is not a compromise. For anyone handling health records, personal data or client files, it is the correct design.

The tension is real, though. Operators want one screen that shows every backup across every site, with enough detail to fix what broke. The vendor hosting that screen wants to be useful. And the easiest way to be useful is to ship everything the client knows up to the cloud: full logs, paths, stack traces, the works.

The problem is that backup telemetry is some of the most sensitive operational data an organization produces. It is a running commentary on every file you own. This article lays out what a hosted dashboard legitimately needs to see, what it should never see, and how to get complete fleet-wide visibility from exception types and identifiers alone.

Logs, paths and error strings leak by default

Nobody designs a backup tool to exfiltrate personal data. It happens as a side effect of being helpful. Consider what an ordinary verbose backup log contains:

• File paths. C:\Users\jsmith\Documents\Patients\Smith, John - MRI 2026-03-14.pdf is a protected health record in its own right. It names a patient, a procedure and a date. A folder called Redundancy 2026 - confidential or Divorce - Anders tells a story before anyone opens a file.

• Error messages. "Access denied to \\fileserver\HR\terminations\Q3\" or "File is locked by outlook.exe (user: maria.hansen@example.com)" carry user names, department names and sometimes email addresses, straight from the operating system.

• Stack traces. A trace from a failed upload may embed the destination URL, the bucket name, a query string, or the local path it was trying to read.

• Warnings and skipped files. A list of "file changed while reading" entries is a list of what someone was working on at 02:00.

• Free-text metadata. Job names ("Dr. Olsen laptop"), machine names and descriptions are typed by humans and routinely contain names.

None of this is file content. The backup payload itself can be encrypted end to end and still leave a detailed trail of who has what, where, in plain text on a third party's servers. Under HIPAA, a file name that identifies a patient is protected health information. Under GDPR, a path that contains a person's name is personal data, and a folder named after a diagnosis is Article 9 special-category data.

The uncomfortable conclusion: if a hosted dashboard ingests raw logs, the hosting vendor is processing protected data, whether or not anyone intended it. That drags the vendor, its cloud provider, its log tooling and its support staff into your compliance scope.

What a dashboard actually needs to answer your questions

Start from the questions an operator asks, not from what the client could send. Across a fleet, the questions are nearly always the same: Did it run? Did it finish? How much did it move? Is anything trending the wrong way? What broke, and is it the same thing breaking everywhere?

Every one of those is answered by numbers, enumerations and identifiers. None of them needs a string a human typed or a path the file system produced.

The first six rows cover everything a fleet view does. The last three are what a technician wants when they sit down at one specific machine. That distinction is the whole design: fleet-wide monitoring needs the aggregate and the category; root-cause work on a single incident needs the detail, and the detail can stay on the machine where it was produced.

Fleet visibility from exception types and IDs alone

The trick is to classify on the client and transmit only the classification. A raw error is a free-form string that may contain anything. An exception type is a fixed vocabulary chosen by the software vendor. It cannot contain a patient name because it is not produced from your data at all.

This is a stronger guarantee than redaction. A redacting client still builds the full report and then strips what it recognizes as sensitive; a path in an unexpected place, or a message format it has not seen before, can slip through. A reduced-reporting client never builds the sensitive fields in the first place. There is nothing to strip, and no filter whose gaps can leak.

A reduced report looks something like this:

That is enough to run an operation. An operator looking at a fleet of 400 machines can see:

• Which machines are red, and why in one word. PermissionDenied on 12 machines, PathNotFound on 1. Different problems, different owners.

• Patterns across the fleet. The same exception type appearing on every machine at one site after a Tuesday change is a permissions rollout, not 40 separate tickets.

• Severity without reading prose. FileLocked on a workstation is routine and usually clears on the next run. PathNotFound on a server that backed up fine yesterday means a share went away, and it goes to the top of the queue.

• A handle on the fix. The help ID is a stable, short identifier for the error condition, such as PermissionDenied, FileLocked, PathNotFound or PathTooLong. It is what you paste into the documentation search, the forum or a support ticket, and it means the same thing on every machine and every version.

When the operator does need the detail, the path, the OS message, the trace, they open the client on the affected machine, or connect to it over an end-to-end encrypted session the dashboard vendor cannot read. The detail is fetched on demand, from the source, by someone already authorized to see that machine's data. It is never copied to the cloud as a side effect of reporting.

Enforce it at the door, not in the client settings

A "don't send logs" checkbox in the client is not a control. It is a hope. Someone will install an older version, restore a config from before the policy, or tick the box back on while debugging. If the server accepts whatever arrives, the protected data lands anyway and the vendor is now processing it.

The server side has to refuse. Concretely, an organization flagged as confidential should get:

1. Ingress rejection. Any report that contains free-text log lines, paths or raw messages is rejected before it is stored. Not sanitized, not truncated: rejected, so there is nothing to clean up afterwards.

2. Owner notification. The organization's administrator is told that a client tried to send a verbose report and from which machine, so the misconfigured client can be fixed. The notification carries the machine ID, not the offending content.

3. Enrollment checks. A client that cannot prove it supports reduced-reporting mode is not admitted to a confidential organization in the first place.

4. An audit trail of the refusals. Every rejected report is a near miss. Logging that it happened, and that it was refused, is exactly what an auditor wants to see.

The principle generalizes beyond backup. Any time a hosted service claims it does not receive a category of data, the real question is: what happens when a client sends it anyway? If the answer is "we'd store it", the claim is a policy. If the answer is "the request fails", the claim is an architecture.

What you give up, and why that is the point

A dashboard that cannot see your data also cannot do some convenient things with it. Be honest about the list, because a vendor who says there is no cost is hiding where the data goes.

• No log drill-down in the web UI. You will not click an error and read the file name in the browser. You will click it, search by its help ID, and then go to the machine.

• No vendor-held encryption keys. If the service cannot see your data, it cannot hold the key that would let it see your data. Key custody stays with you. Lose the key, lose the backup; that is the deal with real end-to-end encryption and it should not be softened.

• No vendor-run backup jobs. Features where the hosted service itself performs the backup, such as a managed SaaS-to-cloud job executed on the vendor's infrastructure, necessarily put data through the vendor's servers. In a confidential configuration those features are switched off, not merely discouraged.

• Support is slower. Your vendor's support engineer cannot pull your logs. They can see the exception type, the counts and the timeline, and they can ask you to run a diagnostic locally and read them the result.

Each of these is a feature that, if present, would make the vendor a processor of your protected data. Removing them is not a limitation of the confidential design; it is the mechanism by which the design works. The right mental model is a hospital's IT department buying a monitoring service: they want the service to know that a system failed, and what kind of failure, and they want it to be structurally incapable of knowing whose record was involved.

Why this matters under HIPAA and GDPR

The two regimes use different words for the same conclusion: the less protected data your monitoring vendor receives, the smaller and simpler your compliance problem.

HIPAA. A vendor that receives PHI on your behalf is a business associate, and every cloud provider or tool that vendor uses to process it is a subcontractor needing its own agreement. File names and error strings that identify patients are PHI. If the dashboard never receives them, the dashboard's hosting stack, log pipeline and support desk can be documented as outside PHI scope, with the technical rejection as evidence. A business associate agreement still makes sense, because the relationship exists, but the agreement is backed by an architecture rather than a promise. The reduced-report design also maps directly onto the minimum-necessary standard: the vendor sees exactly what monitoring requires and nothing more.

GDPR. The same design is data minimization (Article 5(1)(c)) and data protection by design and by default (Article 25) made concrete. Paths and messages that name people are personal data; folder names that reveal health, union membership or religion are Article 9 special-category data, which most organizations have no lawful basis to pass to a monitoring vendor at all. Stripping them on the client avoids the question entirely. It also simplifies international transfers: a dashboard that holds machine IDs, counts and exception types is a far easier thing to describe in a transfer impact assessment than one holding log lines of unknown content. And when a subject access request arrives, the vendor can truthfully answer that it holds no personal data from the backup content, only account metadata.

For both. Breach analysis becomes tractable. If the dashboard vendor is compromised, the question "what could the attacker have seen?" has a short, documented answer: identifiers, timestamps, counts and error categories. Not file names, not patient names, not the Q3 terminations folder. That is the difference between a notifiable breach and an incident report.

How Duplicati applies this: confidential mode

The Duplicati Console applies the design above at two levels: a per-agent reporting mode that any operator can turn on, and an organization-wide confidential mode that Duplicati Inc enables on request.

Every agent, by default: redacted reports. Duplicati agents already redact file paths before sending a backup report to the Console. This minimizes what leaks, and for most organizations it is the right balance between privacy and convenience. It is still a filter applied to a full report on the agent, so it is a best effort, not a guarantee.

Per agent, by the operator: reduced reporting. Any operator can switch an individual agent to reduced reporting. In that mode the agent is structurally unable to send free-text fields: no log strings, no file paths, no raw error messages. The report carries result, timestamps, counts, byte totals, exception types and help IDs, and nothing else.

Per organization, by Duplicati Inc: confidential mode. For organizations handling PHI, special-category personal data or client-confidential material, Duplicati Inc can flag the whole organization as confidential. This is a toggle on our side, done on request, because it removes features and must be enforced in the Console rather than on the client. When an organization is confidential:

• The Console's ingress accepts reduced reports only. A report in any other form is rejected, and the organization owner is warned which machine sent it.

• Agents that do not support reduced reporting are refused at enrollment. Reduced-reporting agents also enforce end-to-end encryption on remote-control sessions, so the relay forwards ciphertext only.

• Duplicati-held key storage and the managed backup runner are disabled for the organization. No encryption keys and no backup payload ever reach Duplicati's infrastructure.

• Access to confidential organizations is written to a tamper-evident audit log.

The difference between the two levels is who holds the guarantee. Reduced reporting on an agent protects that agent's data no matter what the Console does. Confidential mode makes the Console refuse anything else, so one agent left in the default mode cannot undo the policy for the organization. Existing organizations can be converted once the owner confirms no protected data was stored under the previous configuration.

One contractual note. Under the Duplicati Terms of Service, storing HIPAA-protected health information or GDPR special-category data while using the Console requires a signed agreement with Duplicati Inc, such as a business associate agreement or data processing agreement, in addition to confidential mode. The technical controls described here are what make that agreement honest; the agreement is what makes the arrangement compliant.

If you run backups for a clinic, a law firm, an HR department or other organization, the question to put to any monitoring vendor is simple: what happens when my client sends you a file name? The answer you want is that the request fails. Confidential mode is Duplicati's answer, and it is available on request to any Console organization.