IT Support Knowledge Base

← All runbooksGeneral

Backups: Setup and Restore Basics

How to set up simple, reliable backups for a PC or Linux machine, and how to test that they can be restored.

Windows 10 / 11 and Linuxabout 4 min read

Symptoms

Use this runbook when:

  • A user asks "how do I back up my files?" (set-up request).
  • A user deleted or overwrote a file and wants it back (restore request).
  • A drive is failing and you need to copy the data off first.
  • You're reviewing whether a small office or home lab has any backup at all.

Before you start

The 3-2-1 rule is an easy guide:

  • 3 copies of your data (the original plus two backups),
  • on 2 different kinds of storage (for example the PC and an external drive),
  • with 1 copy kept somewhere else (cloud, or a drive stored off-site).

Two more rules: a backup you have never tested restoring is only a hope, and a backup drive that is always plugged in can be encrypted or deleted by ransomware along with the original, so keep at least one copy disconnected or in a cloud service with version history.

Also ask: what actually needs backing up? Documents, desktop, photos, email archives (.pst), browser bookmarks, project folders. Programs can be reinstalled, so data matters most.

Steps

Set up a backup on Windows

  1. Cloud folder backup: if the user has OneDrive, Settings > Accounts > Windows backup (Windows 11) lets Desktop, Documents and Pictures sync to OneDrive. (In Windows 10: OneDrive icon > Help & Settings > Settings > Backup > Manage backup.) OneDrive keeps version history and a Recycle Bin online.
  2. File History to an external drive: plug in the drive, then open Control Panel > File History (or search "File History"), choose the drive and Turn on. It keeps versions of files in your user folders.
  3. Check it ran: File History shows the last backup time. Set a reminder to look monthly.

Set up a backup on Linux

  1. Mount the backup drive (for example at /mnt/backup). Always do a dry run first; --dry-run shows what would be copied without doing it: 
    rsync -avh --dry-run /home/user/ /mnt/backup/home-user/
rsync -avh /home/user/ /mnt/backup/home-user/
    The trailing / on the source matters: it copies the contents of the folder.
  2. Add --delete only when you really want the backup to mirror deletions (it removes files from the backup that no longer exist in the source). Always dry-run first.
  3. Automate with cron (crontab -e), for example every night at 02:00: 
    0 2 * * * rsync -a /home/user/ /mnt/backup/home-user/ >> /var/log/backup.log 2>&1
    (Make sure the drive is mounted at that time, and that the user running cron can write the log file.)
  4. For versioned, encrypted backups, tools like restic or borgbackup are popular choices. Read their documentation before relying on them.

Restore a file

  1. Ask: the exact name, location, and when it was last good. Don't overwrite anything yet.
  2. Windows: right-click the file's folder > Restore previous versions (if available), OneDrive online Recycle Bin / version history, or File History > Restore personal files. Restore to a different folder first and confirm it's the right version.
  3. Linux: copy the file from the backup drive with cp or rsync to a temporary location, check it, then move it into place.
  4. Have the user open the file and confirm it is the one they wanted.

Test your backups (do this regularly)

  • Pick a random file, restore it to a different location, and open it.
  • Write down the date of the test. A backup that restored one file last month is far better than one nobody has checked.
  • Check there is enough free space on the backup drive.

Escalate when

  • The backup drive is failing, full, or missing.
  • A business-critical system, server or database has no backup or an untested one.
  • A restore fails, or the data is corrupt or missing.
  • You suspect ransomware (don't connect backup drives to an infected PC; see Malware Cleanup Basics).
  • Data may be subject to retention or privacy rules.

Ticket note template

Request: Backup setup / file restore / data copy from failing drive
Device: | User: | Data to protect: <folders>
Backup method: OneDrive / File History / rsync / other <name>
Destination: <drive name, location> | Off-site or cloud copy: Y/N
First backup completed: <date/time>, size ~ __ GB
Restore test: file <name> restored to <path> on <date> - opened OK Y/N
For restores: file <name>, from <source/version date>, restored to <path>; user confirmed Y/N
Next review date: 
Next step / escalated to:

View as Markdown

How to use this

  1. Search first. Type what the user is describing, like printer offline or locked out. The search reads the whole text of every runbook, not only the titles.
  2. Narrow it down if you want to. The topic links under the search box (Windows, Network, Accounts and so on) trim the list. Click one again, or pick All, to go back.
  3. Open a runbook and read down the page. Symptoms tell you if you are in the right place. Before you start lists the quick questions. Then work through Steps in order, simplest first.
  4. Know when to stop. The shaded Escalate when box lists the signs that it is time to hand the ticket on. If any one of them matches, stop and escalate.
  5. Copy the ticket note. The last section has a note template. Press Copy, paste it into your ticketing system, and fill in the blanks.
Words you will see
Runbook
A written set of steps for one kind of problem, so you do not have to work it out from scratch each time.
First-line support
The first person a user talks to. Fixes the common problems and passes the rest on.
Escalate
Hand a ticket to someone with more access or experience, with notes so they do not have to start over.
Scope
How many people or devices are affected. One laptop and the whole office are very different problems.
Ticket note
A short written record of what was reported, what you tried and what happened.

Why I built this

I'm a computer science student in Toronto and I'm looking for junior IT support and help desk roles. When I started practising troubleshooting, I noticed I knew a lot of individual fixes but not a calm order to try them in, or when to stop and hand a problem on.

So I wrote these twelve runbooks to put that in order for myself, and I built this site so they are easy to search and read. They come from public vendor documentation and common help desk practice. They are not copied from a workplace and they are not real tickets.

They are still a work in progress. If a step looks wrong or something is missing, I would like to know.