Backup & disaster recovery

Ensuring that applications and data can be restored after an incident is one of the most important responsibilities in any IT operation. A good backup and disaster recovery plan reduces downtime, protects against data loss, and provides clarity during stressful situations.

Backup Schedule

Different types of data require different backup strategies. At minimum, backups should include:

• Source Code (Git Repositories)
  Code is primarily stored in Git and hosted on platforms such as GitHub, GitLab, or Azure DevOps. These providers replicate data and offer redundancy.

• Databases
  Databases are often the most business-critical component. Run full backups at least once per day. For systems with high change rates, consider multiple full backups per day (e.g., every 6 or 12 hours) to reduce potential data loss.

• Application Files
  User-uploaded content, media, and generated assets should be backed up daily. For large static assets that rarely change, archive them periodically instead.

• Configuration & Infrastructure configs
  Configuration files (server settings, environment variables, deployment manifests, infrastructure definitions) should be stored in a secure and separate location, usually in a Git repository or dedicated configuration management system. The key requirement is that configs must not only exist on the live systems.

Backups should run automatically and be verified for success. Manual backups may be triggered before planned upgrades or risky deployments.

Retention Policy

Not all backups need to be kept forever. A structured retention policy balances cost, compliance, and system importance. More critical systems often justify longer or more frequent retention, while less critical ones may be fine with shorter cycles.

A common baseline approach is:

• Daily backups kept for the last 7 days

• Weekly backups kept for the last 4 weeks

• Monthly backups kept for 6–12 months

For highly critical systems (e.g., production databases with financial or customer data), you might also keep yearly archives for several years, either for compliance or extra safety. For less important systems (e.g., test environments), a much shorter retention window may be enough to save cost.

Example of Laravel package that can handle backups: