Check who can delete your backups

Separate backup success from backup survival

A successful backup job says little about who can erase the resulting copy. If the same everyday account can change source files and delete every recovery point, compromise of that account may affect both production and recovery. Understand the deletion boundary before trusting retention labels.

Use supported role views and harmless test data. Do not test permissions by deleting a real retained backup or disabling protection on a production repository.

Inventory destructive privileges

1. List the accounts that administer backup settings, storage and retention. Include separate storage-provider accounts if the destination is managed outside the backup application.
2. Identify which roles can delete snapshots, shorten retention, remove encryption keys or change the destination. Reading a backup and destroying it are different privileges.
3. Compare those roles with ordinary user and service accounts. Reduce unnecessary destructive access using supported controls and an approved change process.
4. Protect administrator authentication and recovery. Keep required access available from a trusted route that does not depend entirely on a potentially affected workstation.

Verify without harming recovery

Create a disposable test backup in an explicitly separate test area if your product supports it. With an authorised test account, confirm that the intended restricted role cannot delete it. If safe testing is unavailable, document the configured permission and the verification limit instead of pretending a destructive operation was attempted.

Understand retention features precisely

Read the product's current documentation for immutability, retention locks and deletion exceptions. Features can vary by edition, storage type and account configuration. Do not describe an ordinary recycle bin or a configurable retention period as immutable protection.

If a necessary safeguard is unavailable in the free tools you use, state that limitation. An independent existing offline copy can provide a different survival boundary, but it still needs secure handling and a tested restore route.

Maintain the separation

Review privileges when adding an administrator, changing a storage destination or investigating suspicious activity. Log authorised destructive changes where your system supports it. The objective is a recovery copy whose survival is not casually controlled by every account that can modify the original data, with clear evidence of what your actual configuration protects.