When inspecting our PostgreSQL backup directory, we noticed bizarre filename patterns like:

postgres_db_dump_20091016.gz.1.1.1.1.1.1.1.1.1.1.1-20091021-20091021-20091021-20091021-20091021-20091021-20091021-20091021-20091021-20091021

Logrotate's debug output reveals it fails to recognize older files due to pattern matching issues:

glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
glob finding old rotated logs failed

The current configuration has conflicting directives:

/var/backup/postgres/postgres* {
    nocompress
    nocreate
}

While the global settings specify:

compress
create 666 root root

The filename explosion occurs because:

• The dateext suffix gets appended multiple times during rotation attempts
• Logrotate fails to match existing files due to the complex naming pattern
• The nocreate directive conflicts with the global creation settings

Here's the fixed configuration for PostgreSQL backups:

/var/backup/postgres/postgres* {
    daily
    rotate 4
    maxage 30
    dateext
    dateformat -%Y%m%d
    extension .gz
    compresscmd /bin/gzip
    compressoptions -9
    compressext .gz
    missingok
    notifempty
    noolddir
    sharedscripts
    postrotate
        # Optional PostgreSQL-specific commands
    endscript
}

To clean up existing malformed files and reset the rotation:

# Remove all malformed backups
find /var/backup/postgres/ -name "postgres_db_dump*.1.1*" -delete

# Force initial rotation
logrotate -vf /etc/logrotate.d/postgresql

Implement these safeguards:

1. Use explicit dateformat to control suffix generation
2. Maintain consistent compression settings
3. Test configurations with logrotate -d before deployment
4. Monitor rotation results for the first few cycles

Create a verification cron job:

#!/bin/bash
LOGFILE=/var/log/logrotate_verify.log
CONFIG=/etc/logrotate.d/postgresql

logrotate -d $CONFIG > $LOGFILE 2>&1
if grep -q "error" $LOGFILE; then
    mail -s "Logrotate Config Error" admin@example.com < $LOGFILE
fi

---

When dealing with PostgreSQL backup files, I encountered a peculiar issue where logrotate was generating excessively long filenames like:

postgres_db_dump_20091016.gz.1.1.1.1.1.1.1.1.1.1.1-20091021-20091021-20091021-20091021-20091021-20091021-20091021-20091021-20091021-20091021

The debug output showed logrotate failing to recognize old files:

glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
glob finding old rotated logs failed

The logrotate configuration had several potential issues:

/var/backup/postgres/postgres* {
    nocompress
    nocreate
}

Key observations:

• The dateext option was enabled but conflicting with numbered rotation
• No specific rotation pattern was defined for PostgreSQL backups
• The configuration mixed global and specific settings

Here's a corrected configuration that worked for my PostgreSQL backups:

/var/backup/postgres/postgres* {
    daily
    rotate 7
    missingok
    notifempty
    nodateext
    extension .gz
    compresscmd /bin/gzip
    compressoptions -9
    compressext .gz
    create 640 postgres postgres
    
    # Prevent the long filename issue
    nocreate
    sharedscripts
    postrotate
        # Optional: reload PostgreSQL if needed
        # /usr/bin/pg_ctl reload
    endscript
}

1. Disabled dateext (nodateext) to prevent date suffix conflicts
2. Explicitly set compression options to avoid ambiguity
3. Added proper ownership settings (create 640 postgres postgres)
4. Simplified the rotation scheme

To verify the changes:

# Test configuration
logrotate -d /etc/logrotate.d/postgresql

# Force rotation
logrotate -vf /etc/logrotate.d/postgresql

The test should now show proper rotation without long filenames:

postgres_db_dump_20091016.gz.1
postgres_db_dump_20091017.gz.2
...

If issues persist:

• Check file permissions in the backup directory
• Verify disk space and inodes
• Ensure no other processes are holding file handles
• Consider using a custom naming scheme if needed