Lustre Backup Strategies
Lustre supports three primary backup strategies. Each serves different needs, and most production sites use a combination.
| Strategy | Scope | Speed | Granularity | Best For |
|---|---|---|---|---|
| File-level backup | Client-side | Slow for large FS | Individual files | Selective/incremental backups |
| Device-level backup | Per-target (MDT/OST) | Fast (streaming) | Entire device | Disaster recovery, hardware replacement |
| lustre_rsync | Changelog-based | Incremental | File-level | Continuous replication to second filesystem |
File-Level Backup (Client-Side)
Performed from a mounted Lustre client using standard backup tools (tar, rsync, cp, commercial backup software).
Advantages:
- Integrates with existing backup infrastructure.
- Selective — back up specific directories, users, or projects.
- Can run from multiple clients in parallel (each handling different subdirectories).
Procedure:
# Example: tar backup of a subdirectory tar czf /backup/project_a.tar.gz /mnt/testfs/project_a # Example: rsync to a backup server rsync -av --xattrs /mnt/testfs/project_a/ backupserver:/backup/project_a/
Key considerations:
- Use
--xattrswith rsync/tar to preserve Lustre extended attributes (striping, project IDs). - For very large filesystems, full backups may be impractical. Use incremental backups by date (
find -newer) or changelogs.
Device-Level Backup
Uses dd, e2image, or zfs send to create an image of an individual MDT or OST device.
Advantages:
- Streaming speed — much faster than file-level for full backups.
- Captures entire device state, including internal metadata.
Procedure:
# ldiskfs: device image backup umount /lustre/testfs/mdt0 dd if=/dev/sda1 of=/backup/mdt0.img bs=1M # ldiskfs: space-efficient backup (skips unused blocks) e2image -ra /dev/sda1 /backup/mdt0.e2i # ZFS: send snapshot zfs snapshot tank/mdt0@backup-20260429 zfs send tank/mdt0@backup-20260429 > /backup/mdt0.zfs # ZFS: incremental send zfs send -i tank/mdt0@previous tank/mdt0@backup-20260429 > /backup/mdt0-incr.zfs
Key considerations:
- The target should be unmounted or have a consistent snapshot (LVM snapshot or ZFS snapshot) before backup.
- Device-level backups cannot selectively restore individual files.
lustre_rsync (Changelog-Based Replication)
Uses Lustre changelogs to replicate changes from a source Lustre filesystem to a target filesystem. Ideal for maintaining a warm standby or replicating to a remote site.
See Lustre Rsync Replication for full setup instructions.
Decision Tree: Which Strategy to Use
Need to restore individual files? YES → File-level backup NO → Continue Need disaster recovery for a single target device? YES → Device-level backup NO → Continue Need continuous replication to a standby filesystem? YES → lustre_rsync NO → Continue Default recommendation: - MDT device-level backup (weekly) — CRITICAL - File-level incremental backup (daily) for important data - lustre_rsync for sites that need warm standby
MDT Backup Is Critical
Always maintain regular MDT backups. The MDT contains all filesystem metadata — file names, directory structure, file layouts, permissions, and striping information. Losing the MDT without a backup means losing the entire filesystem namespace, even if all OST data is intact.
An MDT is typically a few TB at most, so device-level backups are fast and practical. Even a week-old MDT backup is vastly preferable to total filesystem loss.
Target-Level Filesystem Backup
An alternative to raw device images: use tar or rsync on the underlying MDT/OST filesystem (mounted as ldiskfs or accessed via ZFS). This preserves the data but allows changing formatting parameters (inode ratio, filesystem features) on restore.
# Mount the backend filesystem mount -t ldiskfs /dev/sda1 /mnt/mdt0_backend # Backup with xattrs preserved tar cf /backup/mdt0_files.tar -C /mnt/mdt0_backend --xattrs --xattrs-include='*' .
This takes longer than dd/e2image due to per-file overhead, but uses less space than a full device image.