sa2 turns a sysstat daily activity file into a readable sar report on a schedule, and it quietly cleans up old files while it does it. You will finish knowing which day gets summarised, how to run it manually, and when it is allowed to remove old files. The examples match sysstat 12.6.1-2 on this Debian system.
sysstat package and a shell.sa2 normally needs elevated privileges, because it writes below /var/log/sysstat and performs retention and compression work. Do not run the write step on a production host until you know which files it manages.Start by checking the package version and the exact script path. This does not change anything:
$ dpkg-query -W -f='${Package} ${Version}\n' sysstat
sysstat 12.6.1-2
$ command -v sa2 || true
$ ls -l /usr/lib/sysstat/sa2
On Debian, sa2 is a shell script at /usr/lib/sysstat/sa2, designed for scheduled use, and it accepts most sar flags and parameters. The portable invocation is the full path followed by any report-selection options:
$ sudo /usr/lib/sysstat/sa2 -A-A asks sar to include every available report section. Treat this as state-changing: it creates or replaces the current report and may remove or compress older files.
Checkpoint: Stop here if the package is missing, the path differs, or you do not yet know which directory holds the host's activity files.
The local script defaults to yesterday's summary. That is deliberate: the usual scheduled run happens shortly after midnight, once yesterday's data is complete. A run made late in the evening can instead be set to report today with YESTERDAY=no in /etc/sysstat/sysstat.
/var/log/sysstat.sa25 for data and sar25 for its report.HISTORY exceeds 28, the script switches to unambiguous names such as sa20260925 and sar20260925. The collector must also use sadc -D for that scheme, so raising HISTORY alone is not a complete change.Read the active settings before scheduling anything:
$ sed -n '1,160p' /etc/sysstat/sysstat
$ find /var/log/sysstat -maxdepth 1 -type f -printf '%f\n' | sort | tail
Do not infer the date from the wall clock alone. Check the filename convention and the report header instead. On this host, reading the existing previous-day file produces a header like:
$ /usr/bin/sar.sysstat -f /var/log/sysstat/sa25 | sed -n '1,4p'
Linux 6.8.0-139-generic (server.example.com) 09/25/26 _x86_64_ (8 CPU)
00:00:01 CPU %user %nice %system %iowait %steal %idle
Your hostname, kernel, date and values will differ. The check that matters is that the header date matches the activity day you actually intended to report.
First confirm the source data file exists. This is read-only:
$ test -r /var/log/sysstat/sa25 && echo 'source data is readable'
source data is readableReplace sa25 with the file for the day you selected, then run the report generation step:
$ sudo /usr/lib/sysstat/sa2 -AThe script picks the source file itself, from the configured date rule, and writes the matching sarDD or sarYYYYMMDD file in SA_DIR. It normally prints no report to the terminal, so verify the output file and read it separately:
$ ls -lh /var/log/sysstat/sar25
$ /usr/bin/sar.sysstat -f /var/log/sysstat/sar25 | sed -n '1,12p'If the source file is absent, sa2 exits without generating a report. Treat a non-zero status, permission error or empty-looking result as a reason to inspect the source path, date setting and service logs, not as a reason to repeat the command.
Recovery: There is no general undo for replacing a report. Before a manual production run, copy the existing report to a protected temporary location, or take the host's normal backup route. If an old report was removed or compressed by retention, restore it from that backup; rerunning sa2 cannot recreate historical data.
The script removes matching sa and sar files older than HISTORY days, and compresses uncompressed matching files after COMPRESSAFTER days. The installed defaults are HISTORY=7, COMPRESSAFTER=10, ZIP="xz" and UMASK=0022. The actual number of surviving files can run a little higher than the nominal history, because removal works in whole 24-hour periods.
Retention is not limited to reports: it also matches daily data files, so a short history can quietly remove the raw data a later analysis needs. A longer history may require the long date naming change above. Treat edits to /etc/sysstat/sysstat as an administrative change: back up the file, make one change, run a controlled check, and restore the backup if the policy turns out wrong.
To keep reports but stop generating new ones, the configuration supports REPORTS=false. That still leaves the cleanup logic running, so it is not a switch that freezes the directory. To stop all changes, disable the scheduler that invokes the script and handle the operational consequences explicitly.
The upstream manpage shows a root crontab example, a weekday run at 19:05:
5 19 * * 1-5 /usr/lib/sysstat/sa2 -ADo not paste that line blindly into a second scheduler. This Debian installation has its own package-managed scheduling and may also use a systemd timer. Inspect the existing jobs first:
$ systemctl list-timers --all | grep -i sysstat || true
$ grep -R "sa2\|sysstat" /etc/cron.d /etc/cron.daily 2>/dev/nullDuplicate schedules can repeatedly rewrite the same report and make retention timing hard to reason about. If you add a job, keep it as root, set the time relative to YESTERDAY, and test it once against a known data file. Remove only the job you added if it proves wrong; leave the package-managed scheduler alone.
/usr/lib/sysstat/sa2 path.SA_DIR, the date rule and the source data file, checked before generating anything.sar.sysstat -f.sa2 writes reports and also removes or compresses old matching files.