Does enabling default journal compression in Arch Linux affect log persistence across reboots?

No. Enabling Compress= in journald.conf does not affect whether logs survive a reboot, and you do not need to disable it for reliable troubleshooting. Compression and persistence are independent settings: Storage=persistent decides where logs are written, while Compress= only controls how the journal files are encoded on disk.

Confirmed behavior

• With Storage=persistent, journal files are written to /var/log/journal and survive reboots, regardless of the compression setting.
• journalctl decompresses entries transparently when reading. You query compressed journals exactly the same way as uncompressed ones; there is no manual decompression step.
• Disabling Compress= buys you nothing in terms of reliability or retention — it only increases disk usage.

What actually determines whether logs persist

If logs are missing after a reboot, compression is almost certainly not the cause. Check these instead:

1. Storage mode. Storage=volatile (or auto without a persistent directory) keeps logs in /run/log/journal, which is tmpfs and is wiped on every boot. Compression cannot rescue volatile logs.
2. The persistent directory. /var/log/journal must exist and be writable. On some systems it is created on demand; if it is missing, journald falls back to volatile storage.
3. Retention limits. SystemMaxUse, SystemMaxFileSize, and MaxFileSec cause rotation and deletion of older journals. Compressed files actually help here, since they hold more history within the same size budget.
4. Corruption. An unclean shutdown can corrupt journal files, making entries unreadable no matter what Compress= says.

Verify on your system

Defaults can vary, so confirm the actual configuration rather than assuming:

grep -E '^(Storage|Compress)' /etc/systemd/journald.conf
systemctl status systemd-journald
ls /var/log/journal

Then, after a reboot, confirm prior boots are visible and readable:

journalctl --list-boots
journalctl -b -1        # logs from the previous boot
journalctl --verify     # integrity check of journal files

If journalctl -b -1 returns entries, persistence and transparent decompression are both working. If it returns nothing, the problem is the storage mode or a missing /var/log/journal — not compression.

Recommendation

Keep Compress= enabled (it is the sensible default and saves disk space), set Storage=persistent explicitly, and ensure /var/log/journal exists. If you still lose logs across reboots after that, share the output of journalctl --list-boots and the Storage= line from your config — that will pin down whether the issue is volatile storage, rotation limits, or file corruption.