Restore settings or change the backup job

When a backup job fails or starts behaving oddly, the first decision is whether to restore settings or change the job. Restoring settings rolls the job back to a saved configuration; changing the backup job edits how it runs now. Use restore when the last change probably broke a configuration that used to work. Use edit when the job is still healthy but the source, target, schedule, or retention no longer fits the environment.

What each choice really does

Restoring settings puts back a saved version of the job’s configuration. That can include the source list, destination, retention, credentials, exclusions, schedule, and any other options the product stores with the job. You are not adjusting the job one field at a time; you are replacing the current setup with a known earlier state.

Changing the backup job means editing the job where it stands. You keep the same job and update the parts that no longer fit: maybe the source path changed, the backup target moved, the schedule no longer matches the maintenance window, or retention needs to be different. This is a forward-looking change, not a rollback.

For example, if yesterday’s backup failed right after someone changed the destination path, restoring settings would put the old destination back. Changing the job would mean updating the destination to the correct new path if the move was intentional. That difference matters because one choice assumes the old setup was right, while the other assumes the job now needs new rules.

When the backup job used to work and then stopped

If the job worked before and then broke right after a change, restoring settings is often the safer first move. That pattern points to a bad edit, a broken credential update, or a corrupted saved config rather than a flawed job design.

Say you changed the backup account password, edited the destination, and the next run failed with an authentication error. If nothing else changed in the environment, rolling back to the last known good settings can tell you quickly whether the new setting caused the failure. The same logic applies if a schedule change, exclusion change, or retention change lines up exactly with the start of the problem.

This does not mean you should restore immediately. First check whether the change was intentional and documented. If the team meant to switch to a new target or new credentials, restoring settings may briefly make the job work again while undoing a valid business change. In that case, the real task is to correct the new configuration, not revert the job.

When the job has the wrong source, target, or schedule

If the backup setup is still valid but the environment changed, edit the job instead of rolling it back. A job that backs up the wrong server, writes to the wrong storage, or runs at the wrong time needs a new configuration, not an old one.

Common examples include a server rename, a storage migration, a new VM path, a new backup window, or a policy change that shortens or lengthens retention. In those cases, the old settings may still be healthy, but they are no longer correct for the current system.

For example, if a file server moved to a new share and the job is still pointing at the old share, restoring settings only preserves the mistake. Editing the job to point at the new source is the direct fix. The same is true if the job runs too late and collides with production work. Changing the schedule is the right answer; restoring a saved schedule just takes you back to the old timing issue.

Signs the problem is in the settings, not the job itself

A settings problem usually shows up when the job structure still makes sense, but one stored value has gone bad. Look for symptoms that point to a configuration item rather than the job design.

• The failure started right after a recent edit.
• The error mentions credentials, permissions, missing paths, or an invalid target.
• A restore point or saved profile exists from before the problem began.
• The same job works if you duplicate it with the older settings.
• A reset or revert option matches the symptom exactly, such as a changed password or a bad destination.

If you can compare the current config with the last known good version, do that before you restore anything. If one field changed and the rest of the job still looks right, the saved settings are the likely problem. If the current setup was intentionally updated and the job still fails, editing may still be wrong for another reason, but restoring is the cleaner test.

If the job fails the same way after you restore the last known good settings, stop treating it like a settings problem. At that point the issue is probably external: the source changed, the storage side changed, or permissions shifted outside the job. Restoring again only hides that.

Signs you should edit the job instead of rolling anything back

Edit the job when the workflow is doing what it was told to do, but the instructions are no longer right for the business need. The job may be healthy and still be wrong.

Warning signs include a new server or share that has not been added, a larger data set that no longer fits the old storage target, a retention rule that now conflicts with policy, or a schedule that misses the backup window. If the job design still matches the old environment but not the current one, restoring settings only preserves the mismatch.

Another clue is repeated success with the wrong outcome. A job can complete without error and still back up the wrong source, write to the wrong repository, or keep data far longer than intended. In that case, you are not dealing with a broken config so much as an out-of-date job definition. Change the source, target, schedule, exclusions, or retention rule directly so the job matches reality.

What most guides leave out about risk

Both choices can cause harm if you use them too quickly. Restoring settings can overwrite a working tweak, bring back an old bug, or erase a fix someone made for a reason you have not checked yet. It can also make a failing job look healthier for one run while the underlying cause stays hidden.

Changing the job has its own risk. You may solve the visible failure and still miss the real issue, especially if the error came from a credential expiry, storage permission change, or source-side problem. A small edit can also create a second problem if you adjust one field without checking the others that depend on it.

The safest habit is to compare current settings with the last known good state before you change anything. If the current setup was intentionally updated and the job still fails, editing may be right. If the job broke right after a surprise change, restoring may be right. In both cases, keep a copy of the current configuration first so you can roll back your own fix if needed.

A simple way to choose the safer next step

Start with what changed last.

1. Check the timing of the failure. If the job broke right after a config change, suspect the saved settings first.
2. Check whether the source, target, or schedule still matches the real environment. If the environment changed and the job did not, edit the job.
3. Check for signs of corruption or missing values. If a credential, path, or destination looks wrong in the saved config, restore the last known good settings if you have them.
4. Check whether the job is failing for the same reason after a restore. If yes, stop restoring and look at the source system, storage, or permissions.
5. Choose the least disruptive fix. Restore only when you are confident the old setup was correct. Edit the job when the old setup is simply outdated.

If you are still unsure, clone the job or export the current config first, then test your change on the copied version if your tool allows it. That gives you a safer path than overwriting the only working setup you have.

How to confirm the fix without waiting for the next disaster

Do not wait for the next scheduled run to find out whether you fixed the problem. Verify the change right away with a short check that matches the failure.

Start with a manual run or a test run if the backup tool supports it. Then review the job log for the exact source, target, credentials, and timing that matter to your case. If the job completes, confirm that it touched the intended source and wrote to the intended destination, not just that it exited cleanly.

If the fix was a rollback, watch the next run closely for signs that the old issue returned. If the fix was an edit, compare the current job settings with the intended design and save the working version once you know it behaves the way you want.

If the backup protects important data, do a small restore test too. Restore a single file, a small folder, or another low-risk sample so you know the backup is usable, not just successful on paper.

Conclusion

If the backup failed after a recent change, restoring the last known good settings is usually the safer first move. If the job is still valid but the source, target, or schedule no longer matches the environment, edit the job instead. Before you touch either one, compare the current config with the last working state, save a copy of what you have, and check the exact error message. Then run a manual test and verify the result in the logs so you know the fix really took.

Frequently Asked Questions

Should I restore settings before editing the job if I am not sure what changed?

Usually, yes, but only after you compare the current config with the last known good version. If the job broke right after a configuration change, a restore is the safer first test. If the environment changed and the job did not, edit the job instead.

What if restoring settings makes the job work again?

That usually means the current configuration was the problem. Do not stop there. Check what changed so you do not leave the underlying cause unresolved. You may still need to reapply a corrected version of the change instead of keeping the rollback forever.

Can changing the job hide the real issue?

Yes. A job can be edited into working shape while a credential, permission, or storage problem remains elsewhere. That is why you should always confirm the fix with logs and, if possible, a small restore test.