The Academy

Loading the search index…

Searches the academy on this device only.

Services, logs, storage and backups for administrators

Learn to check that background services are running, read logs to find out what happened, watch disk space before it runs out, and design a backup you have actually tested by restoring from it.

30 minintermediateUbuntu/LinuxWindowsPractical task needs a laptop or desktop

Marking a lesson as read does not prove you can do it. Skills count as demonstrated when you pass the quiz (not yet) and complete the practical tasks (not yet).

By the end of this lesson you will be able to

  • Explain what a service is and list the running and failed services on your computer.
  • Find and read recent error entries in the system log.
  • Check how much disk space is used and find which folders are using it.
  • Design a backup with a retention rule and carry out a restore drill.

Most problems an administrator meets do not appear suddenly. A service stops quietly, a log fills with warnings for weeks, a disk creeps towards full, or a backup silently fails. The habit of checking these four things regularly turns surprises into small, planned jobs. In this lesson you will learn to look at services, logs and storage, and to build a backup that you have proved works by restoring a file from it.

Services: programs that run in the background

A Service is a program that runs in the background without a window, usually starting when the computer starts. Examples are the program that keeps your clock correct, the one that manages Wi-Fi, and the one that prints. On Ubuntu, a manager called systemd starts, stops and watches services. On Windows, the Services tool does a similar job. If a service stops, whatever depends on it stops too, which is why a printer may vanish when the print service fails.

An administrator's first questions are simple. Is the service running? Did it fail? Does it start by itself after a restart? Look first, and only then restart a service, because a restart can interrupt people who are using it.

Diagram

A service moves between a few states, and a failed one needs a look at its log.

  1. Step 1: StoppedNot running
  2. Step 2: StartingManager launches it
  3. Step 3: RunningDoing its job
  4. Step 4: FailedRead the log first
A service moves between a few states, and a failed one needs a look at its log.
Read this figure as text

A flow of a service from stopped to starting to running, with a failed state that leads to reading the log.

A flow of four steps. 1 Stopped: the service is not running. 2 Starting: the manager launches it at boot or on request. 3 Running: it is doing its job. 4 Failed: if it crashes or cannot start, read its log to find why before restarting. A running service can also be stopped on purpose.

Look at services (read-only)

The command systemctl talks to systemd. systemctl list-units --type=service --state=running lists services that are running now. systemctl --failed lists services that failed, and prints 0 loaded units listed when none did. systemctl status cron shows the state of one service, here the scheduler named cron, together with its last few log lines. These commands only read. Starting, stopping or restarting would need sudo, so do not do that yet.

Terminal (Linux) · you can run this on your own computer
systemctl --failed
systemctl list-units --type=service --state=running
systemctl status cron
Text
  UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.
Example output of the first command when all is well

Logs: the computer's diary

A Log file is a record of events with the time each happened: a service starting, a login failing, a disk reporting an error. Logs answer the question what happened, and when. They also give you the exact words of an error message, which you can search for, as you practised in the troubleshooting modules. Most entries are routine. Your job is to look for the lines marked as errors or warnings near the time the problem began.

Simulated interface: not a real screenshot

Reading error entries from the current start-up with journalctl.

Terminal (simulated)
  1. Marker 1: When it happened
  2. Marker 2: Which program, and what it said
  3. Marker 3: Search the exact message
Reading error entries from the current start-up with journalctl.
Read this figure as text

A simulated terminal listing three error lines from the system journal with markers on the time and message.

A simulated bash terminal. The command journalctl -p err -b --no-pager prints error-level entries since the last boot. Output lines begin with a date and time, the computer name, a program name and the message. Marker 1 points to the time of the first line, Oct 26 08:02:11. Marker 2 points to the program name, wpa_supplicant, and its message that a Wi-Fi connection was lost. Marker 3 points to the second program, cupsd, with a printer message. The entries are fictional examples.

Read the log

On Ubuntu the journal is read with journalctl. The option -p err shows entries of error level and above, -b limits them to the current boot, and --no-pager prints directly instead of opening a scrolling viewer. journalctl --disk-usage shows how much space the journal itself uses. If you see too few lines, your account may not be allowed to read the whole journal: members of the adm group can, which includes the first account created on Ubuntu.

Terminal (Linux) · you can run this on your own computer
journalctl -p err -b --no-pager | tail -n 20
journalctl --disk-usage

Storage: watch the space before it runs out

A full disk causes odd faults: updates fail, programs refuse to save and the computer slows down. The usual error on Linux is No space left on device. An administrator checks Disk usage regularly and acts when a disk passes about 80 per cent full, well before it reaches the limit. Acting means finding what takes the space, then archiving or removing files you no longer need, always after checking that a backup exists.

Check disk space

df -h shows each mounted disk with its size, used space, free space and percentage used, in human-readable units (the h). du -h --max-depth=1 ~ | sort -h | tail -n 6 shows the size of each folder directly inside your home folder, sorted so the largest are last. The | sends the output of one command to the next. Both commands only read.

Terminal (Linux) · you can run this on your own computer
df -h /
du -h --max-depth=1 ~ | sort -h | tail -n 6
Text
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  233G  141G   81G  64% /
Example output of df -h /
Diagram

Bars make it obvious which folders are using the space.

Videos
48 GB
Downloads
22 GB
Pictures
15 GB
Music
9 GB
Documents
2 GB

Example sizes. Start with the largest bars.

Bars make it obvious which folders are using the space.
Read this figure as text

A bar chart of example folder sizes showing Videos largest and Documents smallest.

A bar chart of example sizes in a home folder. Videos 48 gigabytes, Downloads 22 gigabytes, Pictures 15 gigabytes, Music 9 gigabytes, Documents 2 gigabytes. Videos and Downloads together use more than half of the used space, so those are the first places to review. The figures are examples.

Backups: design them, then prove them

You met the 3-2-1 rule earlier: three copies, on two kinds of storage, with one copy away from the building. An administrator adds three more decisions. First, what to back up: the data that cannot be replaced, such as documents, photos and the shop's records, rather than the whole operating system. Second, how often: as often as you can afford to lose work. Third, a Retention policy: how long old copies are kept before they are replaced. A common simple choice is to keep daily copies for a week and monthly copies for a year, though your needs may differ.

The most important rule is that a backup you have never restored is only a hope. Backups fail for dull reasons: the drive was full, the wrong folder was selected, the copy is corrupt. A Restore drill is a planned test in which you restore a few files to a different place and check that they open. Do it after setting up a backup and then every few months.

Diagram

A restore drill proves the backup works before you need it.

  1. Step 1: Pick filesOne recent, one old
  2. Step 2: Restore elsewhereNot over originals
  3. Step 3: Open themAre they complete?
  4. Step 4: CompareSize or content
  5. Step 5: RecordDate and result
A restore drill proves the backup works before you need it.
Read this figure as text

A flow of five steps from choosing test files to recording the result of the restore drill.

A flow of five steps. 1 Pick a few files, including one recent and one old. 2 Restore them to a different folder, never over the originals. 3 Open each and check it is complete. 4 Compare size or content with the original. 5 Write down the date, what worked and what to fix.

Practise a safe copy and restore on your practice folder

rsync copies files and only transfers what changed. In rsync -av --dry-run ~/practice/ ~/practice-backup/, -a keeps file details, -v prints each file and --dry-run only shows what would happen without copying anything. Remove --dry-run to do the copy. The trailing slash on the first folder means copy what is inside it. This command does not delete anything from the destination, because the --delete option is not used.

Terminal (Linux) · you can run this on your own computer
mkdir -p ~/practice
rsync -av --dry-run ~/practice/ ~/practice-backup/
rsync -av ~/practice/ ~/practice-backup/

Common mistakes

  • ✖ Instead of: Restarting a service as soon as something looks wrong.

    ✔ Do this: Check its status and read its log first. A restart can interrupt users and hide the evidence of what went wrong.

  • ✖ Instead of: Assuming the backup works because there is no error message.

    ✔ Do this: Do a restore drill: restore a few files elsewhere and open them.

  • ✖ Instead of: Waiting until the disk is full before looking at it.

    ✔ Do this: Check disk use monthly and act at about 80 per cent.

  • ✖ Instead of: Pasting a full log into a public forum.

    ✔ Do this: Copy only the relevant lines and remove names, addresses and other personal details first.

If something goes wrong

journalctl shows No journal files were found or very few lines.
Your account may not be allowed to read the whole journal. Check that you are in the adm group with groups. Ask the administrator, or look only at your own entries.
systemctl status cron says the unit could not be found.
Not every installation has the same services. Run systemctl list-units --type=service --state=running and choose a service from that list instead.
rsync says command not found.
rsync may not be installed. Ubuntu installs it by default on most desktops, but you can add it later using the package manager once you are comfortable with sudo. Meanwhile, copy the folder using Files.
robocopy finishes with an exit code that is not 0.
Robocopy uses exit codes 0 to 7 for success in different forms, such as files copied or nothing to copy. Only codes of 8 and above mean a real failure.

Key terms

Service
A program that runs in the background, often from start-up, to provide something such as printing or web pages.
systemd
The part of most modern Linux systems, including Ubuntu, that starts services and keeps track of them.
Log file
A record that a system or program writes, line by line, about what happened and when.
Disk usage
How much of a storage device is already filled with data and how much space is left.
Retention policy
A rule that says how long backups or logs are kept before they are deleted.
Restore drill
A practice run in which you bring files back from a backup to prove that the backup really works.

Practise it for real

Reading is not the same as being able to do it. Complete these on your own computer, then tick only what you have actually done. These ticks are your own honest record: nothing checks them for you.

Guided exerciseNeeds a laptop or desktop

Run a ten-minute health check

On your real computer, check four things and write one line for each. First, list any failed services (systemctl --failed on Ubuntu, or the Services tool on Windows). Second, read the most recent error entries in the log and note one entry you do not understand. Third, record how full the main disk is. Fourth, note the date of your last backup. Do not change anything: this exercise is only looking.

You have succeeded when:
Guided exerciseNeeds a laptop or desktop

Do a restore drill with practice files

Create two small text files in your practice folder, copy the folder to practice-backup using the dry run first, then delete nothing. Make a new folder called restore-test, copy one file from the backup into it, and open it to check that it is complete. Write down the date and the result in a file called drill-log.txt inside restore-test.

You have succeeded when:
Independent challenge

Challenge: design a backup for the shop

Joseph's shop keeps customer orders in a spreadsheet and photos of stock on one laptop. Without looking at the lesson, write a backup plan that says what is backed up, how often, where the three copies are, how long old copies are kept and how often a restore drill is done. Then explain why the plan is not complete until the drill has been done at least once.

You have succeeded when:

Knowledge check

7 questions. You need 80% to pass. Mistakes here are part of learning, and you can retry as often as you like.

  1. Question 1.What is a service?
  2. Question 2.The office printer stopped working at about 08:02. Amina opens the log and sees thousands of lines.What is the most useful first move?
  3. Question 3.A backup that has run every night for a year is proved to work, even if nobody has ever tried restoring from it.
  4. Question 4.Put the steps of a restore drill in order.
    1. Open them and check they are complete
    2. Restore them to a different folder
    3. Record the date and result
    4. Pick a few files, one recent and one old
  5. Question 5.Match each command to what it shows.
  6. Question 6.At what point should an administrator act on a filling disk?
  7. Question 7.What does a retention policy decide?

Summary

  • A service is a background program. Look at its status before restarting it.
  • Logs record what happened and when. Narrow to the time of the fault and keep the exact message.
  • Check disk use regularly and act at about 80 per cent full.
  • A backup design says what, how often, where and how long copies are kept.
  • A backup is only proved by a restore drill, so schedule one.

Checklist: can you do these?

Marking a lesson as read does not prove you can do it. Skills count as demonstrated when you pass the quiz (not yet) and complete the practical tasks (not yet).

Related lessons

References and further reading

Official sources for details that can change between versions.

On this page