What this prompt does
This prompt creates a Bash backup rotation script for [backup_target] on a [server_type] server using a grandfather-father-son (GFS) policy. It makes daily backups with [backup_tool] and [compression_type] in [local_backup_path], keeps [daily_retention] daily, [weekly_retention] weekly, and [monthly_retention] monthly copies, generates and verifies SHA-256 checksums, syncs to [remote_destination] via rsync over SSH limited to [bandwidth_limit], sends a summary via [notification_method], runs pre-backup hooks to flush [service_name] to a consistent state, and includes a checksum-verified restore command with a dry-run.
The variables define what is protected and how it rotates. [daily_retention], [weekly_retention], and [monthly_retention] set the GFS depth, [compression_type] and [backup_tool] shape the archives, and [service_name] is flushed before snapshotting so the backup is internally consistent. The restore command with checksum verification and dry-run is what makes the backups trustworthy rather than theoretical. The whole script is built around the principle that a backup is only as good as your last successful restore: the daily summary via [notification_method] keeps the rotation visible, the bandwidth cap via [bandwidth_limit] keeps the offsite sync from starving production, and the integrity checks gate completion so a corrupt archive never quietly takes a good one's place.
When to use it
- Setting up GFS rotation for application files and databases
- You believe an untested backup is not really a backup
- You want SHA-256 integrity checks before marking a backup complete
- Flushing
[service_name]to a consistent state before snapshotting - Syncing backups offsite via rsync with a bandwidth cap
- You need a restore command that verifies checksums and supports a dry-run
Example output
You get a Bash script doing timestamped daily backups with [backup_tool] and [compression_type], GFS retention logic promoting and pruning copies, checksum generation and verification, an rsync-over-SSH sync to [remote_destination] at [bandwidth_limit], a summary notification, pre-backup service-flush hooks, and a restore subcommand that lists backups, verifies the chosen one, and extracts with a dry-run option.
Pro tips
- Actually run the restore command's dry-run periodically; GFS rotation and checksums are worthless if a restore has never been tested
- Flush
[service_name]before snapshotting so databases are captured in a consistent state, not mid-write - Size
[local_backup_path]for the full GFS set; daily plus weekly plus monthly copies add up faster than people expect - Set
[bandwidth_limit]so the offsite sync does not starve the production app of network during business hours - Verify the SHA-256 step gates completion — a backup that fails its checksum should not be marked done or relied upon
- Tune the GFS counts (
[daily_retention],[weekly_retention],[monthly_retention]) to your recovery-point needs rather than copying defaults blindly - Pick
[compression_type]for the right balance: a faster level keeps the backup window short on a busy[server_type], while a higher level saves space offsite but costs CPU during the snapshot
