关于Log4cplus中DailyRollingFileAppender的MaxBackupIndex属性的疑问

DevOps 小满

2026-5-20

Understanding Log4cplus DailyRollingFileAppender's MaxBackupIndex Property

Let me break this down clearly since it’s easy to mix up with cross-day log retention:

First, let’s translate the API doc into plain language: MaxBackupIndex only controls how many numbered backup files are kept within a single log cycle — it has nothing to do with how many days’ worth of date-named logs you retain overall.

When you set the appender to roll DAILY, you’re correct that a new date-stamped file (like log.2024-05-21) gets created each day. But numbered backups (the .1, .2 suffixes) come into play on the same day in one key scenario:

If you’ve also configured a MaxFileSize for the appender (yes, DailyRollingFileAppender supports combining time-based and size-based rolling), once the current day’s main log file hits that size limit, it will be renamed to log.2024-05-21.1, and a new empty log.2024-05-21 is created for incoming logs.
When the new main file hits the size limit again, log.2024-05-21.1 gets shifted to log.2024-05-21.2, the main file becomes log.2024-05-21.1, and this pattern repeats.

MaxBackupIndex sets the hard cap on how many of these numbered files per day you keep. For example:

If MaxBackupIndex=3, you’ll never have more than log.2024-05-21.1, log.2024-05-21.2, log.2024-05-21.3 for that day. When a fourth roll happens, the oldest numbered file (log.2024-05-21.3) gets deleted to make room for the new shifted files.

A critical point to remember: This property does not affect retention of log files from previous days. Your log.2024-05-20, log.2024-05-19, etc., won’t be touched by MaxBackupIndex. If you need to clean up old daily logs, you’ll need an external script or separate tool to handle that.