Backup

Podcast 2 — In conversation

Speaker A: I had a genuine disaster at work last month. My colleague lost three weeks of design work because her laptop died and she had not backed anything up. The whole team was gutted.

Speaker B: That is one of those stories that makes every developer quietly check their backup situation immediately after hearing it. Three weeks of work is painful. The thing with backups is that nobody really thinks about them until they need one — and then it is too late. It is a classic example of a task that is never urgent until it is catastrophic.

Speaker A: She did have a backup from about a month before, so it was not a total loss, but recovering from something like that — it takes more than just restoring files. The confidence in the work is shaken.

Speaker B: Exactly. And that is the thing about backup as a concept — it is not just about data recovery, it is about continuity. In IT project management, we talk about business continuity planning, which is the broader framework. A backup is one component of that. You also need to know how long a recovery takes and whether that is acceptable. A backup that takes four days to restore when you need to be back online in two hours is not a useful backup, however recent it is.

Speaker A: I have heard people use backup and archive almost interchangeably. Are they actually different?

Speaker B: They are meaningfully different, yes. A backup is a copy of current operational data, maintained so you can restore to a recent known state after a failure. An archive is historical data that is moved out of the active system because it is no longer needed for daily work but must be retained — for legal reasons, compliance reasons, or institutional memory. You back up your current customer database. You archive last year's transaction records. The purposes are different: backup is for recovery, archive is for retention. Confusing them in a data management conversation would be a clear register error.

Speaker A: What about redundancy? Is that a synonym for backup?

Speaker B: Close but not quite the same thing. Redundancy in IT refers to duplicated systems running simultaneously so that if one fails, the other takes over immediately with no interruption — think of two power supplies in a server or a mirrored RAID array. A backup typically involves a lag — you restore from a copy that was made at a previous point in time. Redundancy is about zero downtime. Backup is about data recovery. A robust enterprise system usually needs both: redundant live systems and regular backups of those systems. They answer different questions: redundancy asks can we keep running, backup asks can we recover what we had.

Podcast 3 — Prompt engineering

Speaker B: Today's word is backup, and for prompt engineering purposes it is one of the most operationally important words in the developer vocabulary. Every application that touches data must have a backup strategy. Every database design should consider recovery. Backup belongs in prompts for system design, infrastructure planning, application development, and database architecture. Let me walk through the prompts.

Speaker A: I tend to add backup requirements as an afterthought. I should probably be putting them in the initial specification.

Speaker B: Always. Backup strategy is a first-class system concern, not a post-launch addition. Here is a prompt for a simple automated backup feature in a web application.

Speaker B: Build a vanilla JavaScript backup and restore feature for a local-storage-based task management app. The backup button exports all current app data as a downloadable JSON file with a timestamp in the filename. The restore button accepts a JSON file upload, validates its structure against the expected schema, previews the data to the user before applying it, and replaces the current app state after confirmation. Include error handling for malformed files.

Speaker B: The preview before applying is the key UX safety feature. A restore operation is destructive — it overwrites current data. Showing the user what they are about to restore before they confirm prevents accidental rollbacks. The schema validation step means a corrupted or wrong-version backup file does not silently break the application state. These are the two failure modes that catch people out in real backup implementations.

Speaker A: The preview step is something I would not have thought to include without it being specified explicitly.

Speaker B: Always specify the safety gates in your restore operations. Here is a database schema prompt for a backup tracking system.

Speaker B: Design a PostgreSQL schema for a backup management system that tracks scheduled backups for multiple databases across an organisation. Include: a databases table with id, name, environment as an enum of production, staging, and development, and host; a backup_jobs table with id, database_id, job_name, schedule_cron, retention_days, and backup_type as an enum of full, incremental, and differential; a backup_runs table recording each execution with id, job_id, started_at, completed_at, status as an enum of running, success, and failed, file_size_mb, storage_location, and error_message; and an alerts table for failed backups. Add indexes on status and started_at in backup_runs.

Speaker B: The three-tier structure — databases, jobs, and runs — maps exactly to how professional backup systems work. A database has one or more scheduled jobs with different strategies: a nightly full backup and hourly incrementals, for example. Each job produces individual run records. Separating job definition from run execution means you can track the entire history of every backup attempt, including failures and their error messages, which is essential for auditing and compliance.

Speaker A: The retention_days field per job is important — different databases would have different retention requirements.

Speaker B: Exactly — a development database might only retain seven days of backups while a production financial database retains seven years. Here is a Node.js backup utility prompt.

Speaker B: Write a Node.js script that performs a scheduled backup of a PostgreSQL database using pg_dump, compresses the output with gzip, saves it to a local backup directory with a filename containing the database name and ISO timestamp, deletes backup files older than a configurable retention period in days, and logs each operation with timestamp and outcome to a backup.log file. Use only Node.js built-in modules and the pg_dump command-line tool. Include error handling that sends a console alert if the backup fails.

Speaker B: Specifying Node.js built-in modules only prevents the AI from reaching for external packages like node-cron or archiver when perfectly adequate built-in solutions exist. The combination of pg_dump, gzip compression, and automatic old-file deletion implements the essential backup lifecycle in a single maintainable script. The log file output means every backup operation is auditable without needing a separate monitoring service.

Speaker A: The retention cleanup built into the same script means the backup directory does not silently fill up the disk.

Speaker B: Disk management is half of backup management. Here is an application development prompt.

Speaker B: Build a complete document management application with integrated backup functionality. Features: a document library showing all saved documents with title, last modified date, and size; a rich text editor for creating and editing documents stored in local storage; a manual backup button that exports all documents as a single JSON archive; an auto-backup toggle that saves a backup every ten minutes while the editor is open, keeping only the last five auto-backups; a backup history panel showing all available backups with their timestamps; and a selective restore feature where the user can choose which documents to restore from a backup rather than replacing everything. Vanilla JavaScript, clean minimal design.

Speaker B: The selective restore is the most sophisticated feature in that specification and the one most developers omit from their first implementation. Restoring everything from a backup when you only need to recover one accidentally deleted document is destructive — you lose all the work done since the backup was made. Selective restore treats the backup as a browsable source of individual documents rather than an all-or-nothing rollback. The five auto-backup rotation prevents unlimited storage growth while keeping a reasonable recovery window.

Speaker A: Selective restore is the difference between a proper backup system and a blunt rollback tool.

Speaker B: Exactly the distinction. One final prompt — a full infrastructure backup dashboard.

Speaker B: Build a backup monitoring dashboard for a small development team's infrastructure. Show a summary panel with counts of successful backups, failed backups, and overdue backups in the last 24 hours. For each monitored system, show its name, last successful backup timestamp, next scheduled backup, current backup status as a colour-coded badge, and storage used. Include an alert panel listing any backup failures with their error messages and a one-click retry button. Use mock data. Vanilla JavaScript, professional dark dashboard aesthetic, no frameworks.

Speaker B: The overdue backup count is the most operationally critical metric on that dashboard. A backup that was scheduled but never ran — perhaps because a server was offline or a job silently errored — is more dangerous than a backup that failed with an error message, because at least the failure is visible. Overdue means the expected backup window has passed with no result recorded at all. Surfacing that as its own count alongside successes and failures gives the operations team an immediate picture of their actual coverage, not just their scheduled intention.

Speaker A: The gap between scheduled and actually completed is where real backup risk lives.

Speaker B: Always monitor outcomes, not intentions. Backup is one of those words where the concept and the implementation are deeply intertwined — understanding the word means understanding the whole discipline of data resilience.