When security settings should be reviewed for backup issues

If backups stopped updating or a restore can’t reach the right folder, security settings are a likely cause. The usual problem is a changed permission, credential, policy, or account state blocking access at the source, destination, or restore target. Start by checking the account, folder permissions, and any recent security change, then test one small backup or restore before you change anything broader.

What breaks first when security settings are the problem

Security-related failures usually show up in a few clear ways. A backup job may still start and finish, but the backup set stops growing because the job can no longer read part of the source or write to the destination. A restore may work for one path and fail on another folder after a permission change. You may also see access denied, authentication failed, credential expired, or the job may succeed but skip certain files without making that obvious.

The key clue is timing. If the problem began right after a password reset, a new folder was created, a group policy changed, or access was tightened, security settings move near the top of the list. If nothing changed in permissions or accounts and the storage itself is disconnected or full, the cause is more likely elsewhere.

When you should suspect security settings instead of the backup tool

Start with security settings when the backup software still opens, schedules still run, and the failure is tied to a specific account, folder, or path. That usually means the tool is working, but the identity it uses cannot reach something it needs.

Common situations include:

• A backup account password was changed but the job still uses the old saved password.
• A restore is pointed at a new folder that has inherited stricter permissions.
• A source folder was moved under a location with tighter access rules.
• A policy update changed how the machine or account can authenticate to a file share, NAS, or cloud target.

Before you start:

• You need local administrator access on the machine running the backup client, or admin rights in the backup console.
• If the backup target is a network share, you may also need rights on the file server or storage appliance.
• A restart is usually not needed for the first checks.
• A single test backup or restore is enough for validation; do not run a full job yet.

If the failure began immediately after a security change, fix that change first before you rebuild jobs or reformat storage. That keeps the diagnosis focused and avoids making the permissions mess harder to unwind later.

Symptom

Access denied
Authentication failed
Credential expired
The exact message varies

This usually appears when a backup job reaches a source folder it can no longer read, when it tries to write to a destination it no longer has access to, or when a restore target rejects the account that is trying to place files there. The job may also fail only on one path, while other folders continue to work.

Check the source, destination, and restore target in order

1. Check the source first if the backup cannot read files or skips part of a set. Confirm the job account still has read access to the source folder and every parent folder in the path.

Folder > Properties > Security

If the account cannot traverse the full path, the source check failed even if the final folder looks correct. Add only the missing read or traverse access needed for the job, then test again.

2. Check the backup destination next if the job reads the source but does not grow the backup set or cannot save the new data. Confirm the same account has write access to the destination, and if the destination is a network share, check both the share permissions and the folder permissions.

Folder > Properties > Security

If NTFS or folder permissions look right but the share still blocks the job, the share permissions are the problem. If the share allows access but the folder does not, the folder permissions are tighter than the share.

3. Check the restore target if the restore can find the backup but cannot place files in the folder you chose. Confirm the restore account has write or modify access to the target folder, and if the restore must overwrite existing files, make sure it can replace them as well.

Folder > Properties > Security

If the restore fails only on one folder, that usually points to a local permission change, inherited permissions from a parent folder, or a different account being used for the restore than the one you expected.

Make sure the backup credentials still work

If permissions look right, check the credentials the job actually uses. Saved passwords go stale after a reset, and locked or disabled accounts will fail even when the folder ACLs are correct. MFA changes can also break older backup jobs if the tool cannot complete interactive sign-in.

Open the backup job or the credential store used by the product and confirm the saved username matches the account you expect. Then update the password if it was changed recently. If the account is locked out, clear the lockout in your identity system before testing again. If the account was disabled, re-enable it only if that account is still meant to run the job.

For a local Windows account used by a scheduled task or service, confirm the service is still running under the intended identity. If the job uses a network account, make sure it still has rights to sign in to the share or storage system.

Get-ScheduledTask | Where-Object {$_.TaskName -match 'backup'}

If the task or service shows the wrong account, or the password update fails, that points to a credential mismatch rather than a folder permission issue. Fix the stored credentials, then rerun the smallest test backup or restore.

Review recent security or policy changes

If permissions and credentials are correct, review anything that might have changed access rules around the same time the problem started. Endpoint protection can block backup agents from reading protected folders or writing temporary files. Group Policy can remove rights, change password rules, or tighten network authentication. Storage systems can also apply new ACLs, snapshots rules, or share restrictions that block the job.

Look at recent changes in this order:

• Antivirus or endpoint protection exclusions removed from the backup agent, destination path, or restore path.
• Group Policy changes that affect service logon, network access, or file system permissions.
• Storage or NAS permission edits on the target share.
• Folder moves that changed inheritance from a parent directory.

If a security tool is blocking the job, make the narrowest possible exception for the backup application, its service account, or the exact folder it needs. Do not turn off protection for the whole machine unless you are isolating the cause for a very short test and can turn it back on immediately.

Windows Security > Virus & threat protection > Manage settings > Exclusions

If adding a narrow exclusion fixes the job, keep the exception as small as possible and document it. If it does not help, the block is probably not from endpoint protection and you should return to permissions or credentials.

Test with one known file or folder

After any fix, test one known file or one small folder instead of running the full job right away. Pick something you can track easily, such as a text file in a folder you know the account can reach. That confirms the exact path works and keeps the test reversible.

Use the backup app’s test or run feature if it has one. If not, run a small manual backup or restore of a single item. Watch for three things: whether the job completes, whether the file appears in the backup set or restore target, and whether any access denied message appears.

If the small test works, the core security issue is likely fixed. If the small test still fails, the message usually tells you which layer is still blocking access: source read, destination write, or restore target write. That narrows the next check to the right folder, share, or account rather than the whole backup system.

How to avoid this happening again

The best prevention is to separate the backup account from everyday user accounts. A dedicated service account is easier to track, and its permissions can be limited to only the source, destination, and restore paths it needs. Keep a short record of where that account is allowed to read and write.

Also document changes that affect access, such as password resets, folder moves, new shares, policy updates, and endpoint protection changes. If a backup depends on inherited permissions, note the parent folder so a later reorganization does not break access without warning.

After security updates, do a quick log check on the next backup cycle. You do not need a full restore test every time, but you should confirm the job still reads the source and writes to the destination without new access errors. If your environment allows it, use a service account whose password rotation is managed in the same place as the backup job credentials so they do not drift apart.

When the problem is not security settings

If the permissions, credentials, and policies all look correct, the problem is probably somewhere else. Look for destination space issues, disconnected storage, a failed agent service, a corrupt backup job, or an application error in the backup logs. A network share that times out, a disk that is read-only, or a catalog that is damaged can all look like access problems at first.

Signs it is probably not security include:

• The same account can access the folder manually, but the backup job still fails with a storage or engine error.
• The destination is online, but the job reports no space left or the disk is full.
• The restore fails on many paths, not just one protected folder.
• The backup software reports database, catalog, or repository errors instead of access denied.

If you see those signs, switch from permission checks to storage health, service status, and application logs. That avoids wasting time on folder ACLs that are already correct.

Conclusion

If the small test now works, keep the fix narrow and document exactly what changed. If it still fails, move to storage health and backup logs next.

Frequently Asked Questions

Should I check the source, destination, or restore target first?

Check all three, but start with the one tied to the failure message. If the backup cannot read files, start at the source. If it cannot save a backup, start at the destination. If a restore cannot place files, start at the restore target folder.

Can a password change break a backup even if the account still exists?

Yes. The job may still point to the same account name, but the saved password can be wrong after a reset. Locked or disabled accounts can also cause the same kind of failure.

Do I need full control to make backups work?

Usually not. Most jobs only need the specific read and write rights required for their paths. Grant the smallest access that lets the job work, then test it.