Create a cron script that backs up the database every night

## Role and objective

You are a software engineer designing a cron-based database backup solution. Produce a complete, executable implementation package for a nightly database backup, addressed to the person who will configure, run, and verify it. The package must include the script, cron entry, required configuration, failure handling, security considerations, and verification steps. The output is complete only when a technically qualified operator can identify every required value, install the solution, execute a safe test, and determine whether a backup succeeded without relying on invented assumptions.

## Scope and given facts

In scope:

- A script invoked by cron.
- A database backup performed every night.
- Configuration, execution, logging, failure behaviour, and verification.
- Instructions for installation and safe testing.

Confirmed facts from the request:

- The deliverable is a cron script.
- Its purpose is to back up a database.
- The backup cadence is nightly.

Do not infer the database engine, command-line client, credentials method, host, port, database name, operating system, shell, backup location, compression format, retention period, encryption method, notification channel, schedule time, or time zone. Represent each unknown value with a slot and state what supplies it:

- `[FILL IN: database engine and native backup command]` — fill from the actual database platform and its supported backup utility.
- `[FILL IN: runtime operating system, shell, and cron time zone]` — fill from the host that will run the job.
- `[FILL IN: database connection details and credentials mechanism]` — fill from the deployment’s approved secret-management method.
- `[FILL IN: backup destination, retention period, compression, encryption, and notification settings]` — fill from the operator’s backup policy.

Do not expand this into replication, disaster-recovery architecture, schema migration, monitoring-platform selection, or application changes unless required to make the nightly script safe and verifiable.

## Working rules

Use the confirmed facts as the only factual basis. State the language, runtime, dependencies, operating system, shell, database engine, backup utility, destination, schedule, and time zone as confirmed values only when supplied; otherwise use explicit slots. Do not replace a slot with a plausible example.

Define observable acceptance conditions. At minimum, the solution must:

1. Run successfully when invoked manually by the cron execution user.
2. Create a backup at the configured destination.
3. Return exit code `0` only after the backup and any required integrity checks succeed.
4. Return a non-zero exit code on connection failure, authentication failure, command failure, destination failure, integrity-check failure, or insufficient required configuration.
5. Write actionable logs without exposing credentials or secret values.
6. Avoid corrupting or silently overwriting a valid backup.

Preserve existing behaviour by limiting changes to the backup script, its cron invocation, and explicitly required configuration. If the target host already has a backup command, logging convention, or notification mechanism, leave it unchanged unless the user provides permission to modify it; otherwise mark the integration point `[FILL IN: existing behaviour to preserve]`.

Handle branches explicitly:

- If the database engine is supplied, use its documented backup command and label the required dependency.
- If it is not supplied, stop before producing engine-specific executable code and provide a clearly marked implementation template with slots.
- If credentials must be passed through an environment variable or file, do not place secrets directly in the script or cron line; require permissions and ownership to be specified.
- If a backup destination is local, describe capacity and permission checks. If it is remote, require the transport and authentication method as slots.
- If retention or encryption is not supplied, do not invent cleanup or encryption commands; mark them as pending decisions.

For personal data, ask which regime governs the data—`[FILL IN: GDPR, CCPA/CPRA, HIPAA, or other applicable regime]`—and require the retention period and deletion path to appear in the design, not only in comments. For every added dependency, state its licence and whether copyleft terms are acceptable for this project. Do not make unmeasured performance claims.

## Output structure

Order the response exactly as follows:

1. **Goal and stack** — State the nightly database-backup objective, then list confirmed values and unresolved slots for language, shell, runtime, operating system, database engine, backup utility, dependencies, credentials, destination, retention, encryption, notifications, schedule, and time zone. Explain what each slot must be filled with.
2. **Numbered acceptance criteria** — Provide numbered, observable pass/fail conditions covering successful execution, backup artefact creation, exit codes, logging, secret handling, permissions, integrity verification, and preservation of existing behaviour.
3. **Implementation** — Provide the cron-compatible script only when the database engine and required execution values are confirmed. Otherwise provide a non-executable, clearly labelled template that contains `[FILL IN: ...]` slots and cannot be mistaken for production-ready code. Include the cron entry, required file permissions, environment configuration, and installation steps.
4. **Edge cases** — Describe the expected error message or log event, exit code, and recovery action for missing configuration, authentication failure, database unavailability, interrupted execution, insufficient space, permission denial, destination failure, integrity-check failure, duplicate invocation, and retention or encryption settings that remain unresolved.
5. **How it is verified** — Give a safe manual test, a cron-context test, checks for the resulting backup, an integrity-verification procedure, log and exit-code checks, and a restoration test. Do not claim success without evidence from the actual environment.

Keep code, commands, cron syntax, configuration keys, and acceptance criteria itemized. Use short explanatory prose only to clarify decisions, prerequisites, and evidence.

## Style rules

Use a hybrid style: use numbered and bulleted lists for stack values, acceptance criteria, edge cases, commands, and verification checks; use concise narrative paragraphs for scope boundaries, branch conditions, and security rationale. Keep the register operational and precise. Avoid topic-specific clichés such as “seamless,” “robust solution,” “set and forget,” “enterprise-grade,” and “bulletproof.” Do not present a slot as an example value.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable is a cron-compatible nightly database-backup solution, not a general backup strategy.
2. Confirm that every database-specific command is supported by a confirmed database engine; otherwise verify that executable code was withheld and slots were used.
3. Confirm that the database engine, backup utility, host, shell, schedule, time zone, destination, retention, and credentials method were not invented.
4. Confirm that no `[FILL IN: ...]` slot for the database backup has been filled with an arbitrary value.
5. Confirm that the script’s success and failure exit codes are observable and tied to actual backup outcomes.
6. Confirm that connection, authentication, destination, permission, capacity, interruption, integrity, and duplicate-run failures each have stated handling.
7. Confirm that logs do not expose database credentials, tokens, passwords, or secret-file contents.
8. Confirm that retention, deletion, encryption, and personal-data handling are not silently assumed when their governing values are missing.
9. Confirm that every added dependency has a licence field and that copyleft acceptability is represented as a decision or slot.
10. Confirm that any performance statement is supported by measured evidence or removed.
11. Confirm that the response remains within the requested cron-script and nightly-database-backup scope.
12. Confirm that the final verification procedure includes a safe test, cron-context execution, backup validation, and restoration evidence.