System Administrator interview questionsBackup review — what would actually come back round

Purpose

States the round's premise — a green report is a claim, not evidence — so the candidate reads the report for what it does not prove.

Purpose

Reads backup and recovery on a report the candidate did not configure. The separator is whether they check what was backed up against what exists, instead of reading the status column.

Signals to score

• Compares processed sizes with disk sizes and finds that `DOCS01`'s 600 GB data disk has never been in the job
• Reads six months of "success with warning" on `SQL01` as backups that may not restore the databases cleanly
• Explains in plain terms the difference between a copy taken while the database was told to be consistent and one taken mid-write
• Spends little time on `FS01`'s failure on the 12th, because the retry succeeded
• Says a green job proves something was written, not that it restores, and asks when each server was last restored
• Notices that the only restore test on record is a single file from November 2025
• Asks what the report cannot show — servers in no job, and the backup system's own configuration
• Fixes the cause and not just `DOCS01`: jobs that pick up every disk a VM has, and an alert on warnings, not only on failures
• Proposes restore tests with a rota, a scope per server and a written result

Follow-up questions

• `DOCS01` processed 64 GB last night. How big is it?
• `SQL01` has said "success with warning" since March. What exactly would come back?
• The only red mark this month is `FS01` on the 12th. How worried are you?
• When was each of these servers last restored, and how would you find out?
• What is not on this report at all?

Purpose

Reads backup and recovery at the moment a backup has to prove itself, including the copy nobody has used. The separator is whether the candidate establishes when the loss happened before choosing what to restore, and restores beside the live data rather than over it.

Signals to score

• Reads the three empty checks as dating the loss to more than fourteen nights ago, and goes to the offsite copy for anything older
• Finds the last point where the folder still had files by checking points, rather than restoring the oldest one available
• Says the offsite copy has never been restored from and plans for that: credentials, download time for 18 GB, and what to do if it fails
• Restores to a separate location with the original permissions, not over the live folder
• Asks how 2,300 files went, before restoring, in case whatever removed them is still running or still has access
• Tells finance early what is known, roughly how long it will take and what will not come back — anything created between the last good point and the loss
• Checks counts, sizes and a sample of opened files with finance before calling it done
• Notes that auditing would have answered who and when, and proposes switching it on for finance's shares
• Reads a loss noticed after three weeks against fourteen days on site and thirty offsite as a retention decision to revisit

Follow-up questions

• The oldest on-site point from fourteen nights ago shows the folder empty. What do you now know?
• Nobody has ever restored from the offsite copy. What could go wrong in the next hour?
• Why not restore straight back into the Suppliers folder?
• Does it matter how the files disappeared before you restore them?
• Finance noticed after three weeks. What does that tell you about fourteen days?

Purpose

Sets an attacker who already holds the keys, which is the case the setup notes fail and the case a backup design is for.

Purpose

Reads backup and recovery against deliberate destruction rather than accidental loss. The separator is whether the candidate follows the attacker's credentials to each copy instead of listing backup best practices.

Signals to score

• Follows the domain admin account to `BKP01`: it can sign in to the console, delete restore points, or encrypt the repository's disks
• Follows it on to the offsite copy: the software holds a key that can delete, and a bucket with no versions keeps nothing once objects are gone
• Concludes that on Monday there may be no copy at all, and says so plainly
• Proposes a copy that cannot be deleted or shortened inside its retention period, even by the account that wrote it
• Takes `svc-backup` out of Domain Admins and asks what the backup system actually needs to read the VMs
• Moves administration of the backup system off domain accounts, with its own credentials and MFA, so one stolen identity does not reach both production and backups
• Orders the changes by protection bought per day of work, and puts the undeletable copy and the service account first
• Says restores after an attack need checking for what the attacker left behind, and that the restore order — directory first, then what people need — is written down beforehand

Follow-up questions

• The attacker has a domain admin account. What can it do to `BKP01`?
• And to the copy in the cloud?
• What exactly has to be true for the offsite copy to survive?
• `svc-backup` is in Domain Admins. Why do you think it was put there, and what does it need?
• It is Monday and you are restoring. What comes back first, and from which copy?

Purpose

Reads documentation directly, as a piece of work rather than a stated habit. In a team this small the procedure is the colleague who is not there, so the separator is whether the page can be followed by someone else under pressure.

Signals to score

• Opens with when to use the page and who may approve restoring another team's data
• Says where the credentials for the backup console and the offsite copy are kept, and what to do if the console itself is down
• Writes numbered actions, each with what the reader should see if it worked
• Explains how to choose the restore point, including when to go to the offsite copy
• Restores to a separate location by default and says how to hand the files back with their permissions
• Includes checks before telling the requester — file counts, sizes, a few files opened by the person who asked
• Marks how long each stage takes as measured on a real restore, or leaves a blank to fill in at the first test, rather than guessing, and says what to tell the requester while waiting
• Puts at the top when the procedure was last followed from start to finish, and by whom
• Keeps it to a page that works at 03:00, and links to detail rather than including it
• Says what to record in the ticket afterwards so the next person learns from it

Follow-up questions

• Who is this page written for, exactly?
• The backup console will not load on Saturday. What does your page say?
• How does the reader know which restore point to pick?
• How would you know in six months that this page still works?
• What did you leave out on purpose?

Purpose

Scores nothing and goes in the notes. Someone who has had to restore for real tends to ask when it was last done and by whom.

Purpose

Ends on a fact about the team's own backups rather than a pitch. It is what this candidate wants to hear and it only works if it is true today, so check it before the round.