In GitLab 6.8.2 and later versions, the backup retention system works through a combination of configuration settings and the backup rake task. The key parameter gitlab_rails['backup_keep_time'] must be properly configured in /etc/gitlab/gitlab.rb:

# Example configuration for 7 day retention
gitlab_rails['backup_keep_time'] = 604800  # 60 * 60 * 24 * 7

The "skipping" message typically appears when:

• The backup_keep_time value is too small (60 seconds is impractical)
• GitLab hasn't been reconfigured after changing the setting
• Permission issues prevent deletion

Here's the complete workflow to implement automatic backup cleanup:

# 1. Edit the configuration file
sudo nano /etc/gitlab/gitlab.rb

# 2. Set a reasonable retention period (e.g., 30 days)
gitlab_rails['backup_keep_time'] = 2592000

# 3. Reconfigure GitLab
sudo gitlab-ctl reconfigure

# 4. Run the backup task
sudo gitlab-rake gitlab:backup:create

For more control, create a custom cleanup script:

#!/bin/bash
BACKUP_DIR="/var/opt/gitlab/backups"
RETENTION_DAYS=30

find "$BACKUP_DIR" -name "*.tar" -type f -mtime +$RETENTION_DAYS -exec rm -f {} \;

After implementing the configuration changes, you should see output similar to this during backup creation:

Deleting old backups ... done (removed 3 backups)

Remember that:

• Values are in seconds (not days or hours)
• Changes require gitlab-ctl reconfigure
• The setting only affects backups created AFTER configuration
• For GitLab 6.8.2 specifically, this feature was relatively new

---

When managing GitLab instances, regular backups are crucial, but storage management becomes critical as backups accumulate. Many administrators expect the backup_keep_time parameter to automatically handle cleanup, but there's more to it in older versions like GitLab 6.8.2.

The gitlab-rake gitlab:backup:create command creates timestamped backups in the default location (/var/opt/gitlab/backups). While the configuration:

gitlab_rails['backup_keep_time'] = 60

suggests automatic pruning, the "Deleting old backups ... skipping" message indicates the expected cleanup isn't occurring. This is because:

Prior to GitLab 7.10, the backup pruning functionality wasn't fully integrated into the core backup task. The backup_keep_time setting alone won't trigger automatic deletion in version 6.8.2.

Here are two reliable approaches to implement proper backup rotation:

Option 1: Custom Cleanup Script

Create a standalone cleanup script (/usr/local/bin/gitlab-prune-backups):

#!/bin/bash
BACKUP_DIR="/var/opt/gitlab/backups"
RETENTION_SECONDS=60

find "$BACKUP_DIR" -name "*_gitlab_backup.tar" -type f -mmin +$((RETENTION_SECONDS/60)) -delete

Make it executable and add to cron:

chmod +x /usr/local/bin/gitlab-prune-backups
(crontab -l ; echo "0 2 * * * /usr/local/bin/gitlab-prune-backups") | crontab -

Option 2: Enhanced Backup Wrapper

Create a wrapper script that handles both backup creation and cleanup:

#!/bin/bash
# Create new backup
gitlab-rake gitlab:backup:create

# Cleanup old backups
BACKUP_DIR="/var/opt/gitlab/backups"
KEEP_DAYS=1
find "$BACKUP_DIR" -name "*_gitlab_backup.tar" -type f -mtime +$KEEP_DAYS -delete

For production environments, consider upgrading to a newer GitLab version where backup pruning is properly integrated. Modern versions (10.0+) support advanced retention policies through:

gitlab_rails['backup_keep_time'] = 604800 # 7 days in seconds
gitlab_rails['backup_pg_schema'] = 'public'

Remember to reconfigure after changing settings:

gitlab-ctl reconfigure

After implementing any solution, verify with:

ls -l /var/opt/gitlab/backups

Check your backup directory periodically to confirm older backups are being removed as expected.