Garbage Collection 🔗

Garbage Collection (GC) in Proxmox Backup Server (PBS) is a critical maintenance task designed to reclaim storage space by removing unused backup chunks from the datastore. Here’s an overview of its purpose, performance impact, and scheduling:

Purpose of Garbage Collection 🔗

1. Reclaiming Space: GC identifies and safely deletes chunks no longer needed by any backup snapshot.
2. Efficient Storage Management: By removing unused chunks, GC optimizes the datastore and ensures sufficient space for new backups.
3. Two-Phase Process:
   • Mark Phase: Reads all index files to determine which chunks are still in use.
   • Sweep Phase: Deletes chunks that are no longer referenced.

Performance Impact of GC 🔗

1. CPU and Disk I/O Consumption: GC can significantly impact system resources, especially during the mark phase, potentially slowing down other operations like backups or restores.
2. Increased Runtime with Larger Datastores: As the datastore grows, GC takes longer to complete, which can affect overall system performance.
3. Reduced Throughput: High resource usage during GC can lead to slower response times for other server tasks.

GC Scheduling Strategy 🔗

To balance resource utilization and maintain regular cleanup:

• A 2-hour delay is enforced between consecutive GC runs to prevent system overload.
• If no manual GC job is scheduled within this timeframe, the system automatically schedules a new GC job after 2 hours from the last run.

This approach ensures efficient resource management while optimizing storage space regularly.

Backup Verification 🔗

Proxmox Backup Server (PBS) offers built-in verification capabilities to ensure the integrity of backup data. However, in certain configurations, these verification processes may be disabled to optimize system performance without compromising data integrity.

Understanding Verification Jobs 🔗

Verification jobs in PBS are designed to:

1. Check the integrity of backup data
2. Ensure that backups are recoverable
3. Detect potential corruption or inconsistencies

These jobs can be resource-intensive, particularly for large datastores, potentially impacting system performance during execution.

Why Verification is Disabled 🔗

In our current configuration, backup verification is disabled for the following reasons:

1. Use of ZFS as the Underlying Filesystem

   • ZFS provides built-in data integrity features, including:
     • Checksumming for all data and metadata
     • Automatic detection and correction of silent data corruption (bitrot)
     • Self-healing capabilities when used in redundant configurations (e.g., RAID-Z)

2. Resource Optimization

   • Verification jobs can consume significant CPU and I/O resources
   • Disabling these jobs helps maintain system performance for other critical operations

3. Redundant Integrity Checks

   • ZFS regularly performs its own integrity checks through features like scrubbing
   • These checks provide a filesystem-level verification that complements PBS’s application-level integrity

ZFS Data Integrity Features 🔗

ZFS offers robust data protection mechanisms that reduce the need for additional verification:

1. Continuous Checksumming: All data and metadata in ZFS is checksummed, allowing for immediate detection of data corruption
2. Self-Healing: In redundant configurations, ZFS can automatically repair detected inconsistencies
3. Regular Scrubbing: ZFS scrub operations can be scheduled to proactively check and correct data integrity issues

By leveraging ZFS’s built-in features and disabling redundant verification processes, we maintain strong data integrity measures while optimizing system performance and resource utilization.