Configure sysstat Retention and Daily Reports

Disk fills with years of sa files, or a report job quietly stops working, and the fix is the same file: /etc/sysstat/sysstat. This guide configures sysstat's collection options, retention period, compression and daily report behaviour through it. The examples target sysstat 12.6.1, installed here as Debian package version 12.6.1-2. Allow about fifteen minutes, plus time for the next scheduled collection if you want to verify the result without running a reporting job by hand.

You need a shell and sudo access to edit the system configuration. Reading the file and checking timers is unprivileged. Editing it, creating a log directory or restoring a backup needs elevated privileges.

1. Record the installed layout

Start by checking the version, configuration file and current data directory. These commands only read system state:

$ sar -V
sysstat version 12.6.1
(C) Sebastien Godard (sysstat <at> orange.fr)
$ test -r /etc/sysstat/sysstat && echo configuration-readable
configuration-readable
$ ls -ld /var/log/sysstat
drwxr-xr-x ... /var/log/sysstat
$ systemctl list-timers 'sysstat-*' --no-pager
... sysstat-collect.timer ...
... sysstat-summary.timer ...

On this installation, collection runs every ten minutes and the summary timer fires at 00:07. Your schedule may differ if an administrator has overridden the units. The standard data files live under /var/log/sysstat, using names such as saDD and reports such as sarDD.

2. Make a recoverable configuration backup

Before touching retention or collection, make a dated copy. The command below writes only the backup file and does not alter the active configuration:

$ sudo cp -a /etc/sysstat/sysstat /etc/sysstat/sysstat.before-2026-09-27
$ sudo ls -l /etc/sysstat/sysstat.before-2026-09-27
-rw-r--r-- ... /etc/sysstat/sysstat.before-2026-09-27

Replace the date with today's date, and do not use a broad wildcard for the backup name. If the new settings cause a problem, restore this exact copy with:

$ sudo cp -a /etc/sysstat/sysstat.before-2026-09-27 /etc/sysstat/sysstat

3. Choose retention and file names together

HISTORY controls how long sa2 keeps daily data and report files. A value of 28 is meant to cover roughly a month, but removal uses find -mtime, so it is not an exact day count: with 28, the installed script can leave around 30 or 31 files during part of a month.

For more than 28 days, set HISTORY above 28 and let sa1 switch to long date names by passing -D to sadc internally:

HISTORY=90

That produces names like sa20260927 and sar20260927 instead of reusing the day-of-month names. Do not bump HISTORY to a large value assuming the old two-digit files will become date-stamped automatically: the setting affects new collection behaviour and the cleanup calculation, but existing files keep their names.

For a short-lived test host, a smaller value is reasonable. For an audited host, pick the value from the retention requirement rather than from available disk space alone. sa2 removes files older than the configured age, so a mistake here can be destructive.

4. Edit collection and report settings

Open the file as root with an editor:

$ sudoedit /etc/sysstat/sysstat

Keep the assignments as plain shell syntax. This is a representative configuration:

HISTORY=90
COMPRESSAFTER=10
SADC_OPTIONS="-S DISK"
SA_DIR=/var/log/sysstat
ZIP="xz"
DELAY_RANGE=0
# YESTERDAY=no
# REPORTS=false

SADC_OPTIONS is used when a new daily data file is created. -S DISK enables block-device statistics; other optional activity groups include INT, IPV6, POWER, SNMP, XDISK and XALL. An existing data file keeps the activities it was created with, so changing this value does not retrofit older files.

COMPRESSAFTER is the age after which uncompressed data and report files are handed to the program named by ZIP. Check that program actually exists before you select it:

$ command -v xz
/usr/bin/xz

REPORTS=false stops sa2 creating sar report files, but the script still runs its retention and compression checks. YESTERDAY=no makes the report cover today's file, which suits a job run late in the day; the default is yesterday because scheduled summaries commonly run just after midnight. DELAY_RANGE adds a random delay before sa2, and 0 runs it immediately.

5. Validate the edit without starting a report

First check the file is readable and has valid shell syntax:

$ sudo test -r /etc/sysstat/sysstat && echo configuration-readable
configuration-readable
$ sudo sh -n /etc/sysstat/sysstat
$ sudo grep -E '^(HISTORY|COMPRESSAFTER|SADC_OPTIONS|SA_DIR|ZIP|DELAY_RANGE|YESTERDAY|REPORTS)=' /etc/sysstat/sysstat
HISTORY=90
COMPRESSAFTER=10
SADC_OPTIONS="-S DISK"
SA_DIR=/var/log/sysstat
ZIP="xz"
DELAY_RANGE=0

An empty result from that last command means the relevant line is commented out or absent, not that the setting is false. The scripts have defaults, so an omitted REPORTS still permits reports and an omitted YESTERDAY still selects yesterday.

If you set a custom SA_DIR, create it before the next scheduled job and make sure the service account can write there:

$ sudo install -d -m 0755 /var/lib/sysstat-data
$ sudo chown root:root /var/lib/sysstat-data

Do not point SA_DIR at a directory that already holds unrelated files. Cleanup filters names that look like sysstat data or reports, but a dedicated directory gives the retention job a safer boundary to work inside.

6. Verify the next scheduled run

Leave the services and timers alone, then wait for the next collection and summary window. Inspect the resulting files and service logs:

$ ls -lt /var/log/sysstat | head
total ...
-rw-r--r-- ... sa27
$ systemctl status sysstat-collect.service sysstat-summary.service --no-pager
... Active: inactive (dead) ...
$ journalctl -u sysstat-collect.service -u sysstat-summary.service --since "today" --no-pager
...

These oneshot services normally show as inactive after completing, so that state alone is not a failure. Look for a recent successful execution and a new or updated sa file. If reports are enabled and a suitable data file exists, look for the matching sar file. A missing or unwritable custom directory, an invalid ZIP command, or a malformed assignment are more useful first suspects than restarting services.