Datadog Agent rollback lacks guarantee for post‑upgrade configuration preservation

Short answer

No to all three assumptions. The datadog-agent rollback command restores the previous binary from a local cache — it does not automatically restore configuration files modified after the upgrade. The 'Datadog Agent: Manage' RBAC permission governs UI/API actions, not the local CLI rollback, which needs host-level root/administrator rights. And a rollback can usually be done without a reboot, but only if the agent is fully stopped and stale lock files are cleared first.

What rollback actually does

On Linux, the previous agent binary is kept under a cache directory such as /opt/datadog-agent/embedded/.rollback (on Windows, under the install directory). The rollback command swaps the current binary back to that cached copy. It does not touch /etc/datadog-agent/ (or C:\ProgramData\Datadog\). Configuration files you edited after the upgrade stay as they are — which is usually what you want, but if the failed upgrade rewrote or migrated config, you must restore those files from your own backup or configuration management (Ansible, Chef, etc.).

Two consequences follow:

• If the previous version is not in the local cache, the rollback fails unless you supply the package manually or the host can re-download it from Datadog's repositories. The RBAC permission is irrelevant here — cache presence and host privileges decide the outcome.
• Custom integrations shipped as separate packages (e.g., checks installed as wheels) are not rolled back with the binary. Pin and manage their versions independently.

Dealing with a hung rollback after a crash

A crashed agent can leave a stale PID or data-directory lock that makes rollback hang. The safe sequence is:

1. Stop the agent completely: systemctl stop datadog-agent (or stop the Windows service). Confirm no agent processes remain.
2. Remove stale lock/PID files in the agent's run and data directories.
3. Run the rollback, then restart the service.

A reboot is not strictly required if all processes are stopped and locks are cleared. It only becomes the pragmatic option when a crashed process still holds kernel-level resources you cannot cleanly release.

Verifying the rollback

Since documentation does not define "full configuration restoration," verify it yourself:

datadog-agent version        # confirm prior binary version
datadog-agent configcheck    # validate config syntax
datadog-agent status         # confirm custom integrations load and report

Also review /var/log/datadog/agent.log (or Windows Event Viewer) for startup or lock-related errors, and confirm your custom checks actually emit metrics in the Datadog UI.

Caveats

Rollback cache layout and CLI flags differ between Agent v7 and newer major lines — run datadog-agent rollback --help and inspect the cache directory on your host before relying on this in an incident. The UI 'Rollback' button (where available) redeploys via the package manager and may handle configuration differently from the local CLI. Treat the above as well-established general behavior and validate it on one non-production host before depending on it.