Tune sysstat Retention and Daily Reports Safely

You will configure sysstat's collection options, retention period, compression and daily report behaviour through /etc/sysstat/sysstat. 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 manually.

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 requires 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 is scheduled every ten minutes and the summary timer runs at 00:07. Your timer state or schedule may differ if an administrator has overridden the units. The standard data files are under /var/log/sysstat, using names such as saDD and reports such as sarDD.

2. Make a recoverable configuration backup

Before changing retention or collection, make a dated copy. The command 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. 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

This is the recovery path. Keep the backup until a collection and summary have completed successfully.

3. Choose retention and file names together

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

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

HISTORY=90

That produces names such as sa20260927 and sar20260927, rather than reusing the day-of-month names. Do not change HISTORY to a large value while assuming the old two-digit files will become date-stamped automatically. The setting affects new collection behaviour and the cleanup calculation; existing files keep their names.

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

4. Edit collection and report settings

Open the file as root with an editor:

$ sudoedit /etc/sysstat/sysstat

Keep the assignments simple 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 with which it was created, so changing this value does not retrofit older files.

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

$ command -v xz
/usr/bin/xz

REPORTS=false stops sa2 creating sar report files, but the script still performs 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 that 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 the 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 ensure 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 containing unrelated files. Cleanup filters names that look like sysstat data or reports, but a dedicated directory gives the retention job a safer boundary.

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 is not by itself 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.