Reviews Inquire

Automatic backups for a static microsite

A static microsite has fewer moving parts than a database-driven application, but its content, generated pages, domain configuration and publishing history still need protection. Automatic backups turn that protection into a routine: each scheduled run creates a recoverable copy, sends it away from the working server and leaves evidence that the job completed.

Start by deciding what counts as the site, because a copied build folder alone will not preserve everything. A sound plan keeps source files and history in one place, stores a separate copy of important assets, and makes restoration possible without relying on the original host remaining online. It should also tell you who owns the domain and how it can be renewed.

Long-term stewardship matters for small Australian publishers as much as for large agencies. A lean, community-run site may rely on volunteers, a .com.au domain and a few cloud services, so predictable costs and clear ownership records can matter more than elaborate tooling. Older material such as Many Mamas, Many Papas shows how an archived page can retain a meaningful place in a site’s history.

Map the files that need protecting

Treat the live site as a stack with four layers: the repository holding content and templates, the built output, the configuration used to publish it, and the domain or DNS records that point visitors to it. Write each path down before writing any commands. That prevents the common mistake of backing up generated HTML while forgetting the source that produced it.

For a generator such as Hugo, Eleventy or Jekyll, protect the content directory, templates, data files, stylesheets, scripts and build configuration. Keep dependency lock files so the same versions can be installed later. Node modules, package caches and temporary build directories are normally poor backup targets: they are large, replaceable and can introduce unnecessary security risk.

Include uploaded images, downloadable documents and fonts, even when they sit in cloud storage outside the repository. Forms may also send submissions to a third-party service, so document that workflow separately. Secrets such as deployment keys, access tokens and environment files should go to an encrypted password or secrets vault, not into a public Git history or an ordinary archive.

Choose a clear source of truth. If the repository is authoritative, an automatic build can recreate the public directory. If a CMS publishes into the repository, capture its export too. Whichever model you use, write down how a new maintainer would obtain the content, rebuild the site and publish it. This is a small piece of documentation with a large payoff during a handover.

Choose storage that survives local failures

Use at least three copies of important data on two kinds of storage, with one copy off-site. A practical arrangement is the Git hosting service as one copy, an encrypted object-storage bucket as another, and a local snapshot on an external drive as the third. The three-copy rule is less important than knowing that deleting a file cannot delete every version at once.

Choose a storage region deliberately. A bucket in Sydney or Melbourne can suit Australian visitors and keep everyday transfers within the country; an overseas bucket may offer cheaper or more specialised options, but compare network latency and the Australian Privacy Act if your archives contain personal information. Most public static files need little personal data, whereas customer lists or form exports need stricter handling.

Do not treat folder synchronisation as a complete backup. Sync tools often propagate deletions, and a compromised workstation can synchronise harmful changes everywhere. Object versioning, write-once retention and separate account credentials can add useful protection. Keep MFA enabled on the hosting service, restrict backup credentials to the required bucket operations and record who can change retention settings.

A separate backup account is useful even for a small project. It prevents one compromised password from giving an intruder access to both publishing and recovery material. It also makes it possible to disable unnecessary services without accidentally removing the ability to restore an earlier version.

Schedule repeatable backup jobs

Run backups at a time when the site is quiet and the connection is dependable. A 02:00 UTC schedule falls at different hours in Sydney, Melbourne, Brisbane, Adelaide and Perth, so check daylight-saving changes rather than assuming one local time. If the job runs from home, build in retries because NBN availability, mobile coverage and power can vary outside major cities.

On Linux, cron provides a straightforward scheduler; on macOS, launchd can run the same script. Adjust the paths and bucket name, install the required command-line tools, and run the script manually once before enabling the schedule.

#!/usr/bin/env bash
set -euo pipefail

stamp="$(date -u +%Y%m%dT%H%M%SZ)"
backup_dir="/var/backups/site-${stamp}"
mkdir -p "$backup_dir"

git -C /srv/microsite bundle create \
  "$backup_dir/history.bundle" --all

tar -C /srv/microsite -czf "$backup_dir/files.tar.gz" \
  content templates static config

aws s3 cp "$backup_dir" \
  "s3://example-site-backups/site-${stamp}/" \
  --region ap-southeast-2

The scheduler entry can then run the script every morning:

17 2 * * * /usr/local/sbin/backup-site >> /var/log/site-backup.log 2>&1

The Git bundle preserves branches and tags, while the archive captures files needed for a rebuild. Uploading to object storage creates the off-site copy; enabling versioning or lifecycle rules in the bucket prevents storage from growing without bound. If the site is built on each deployment, an alternative is a GitHub Actions, GitLab CI or similar job that archives the output and records a deployment identifier in a private history repository.

Keep credentials out of the script and log files. On a managed runner, store access keys or workload identity in the platform’s secret store and grant only permission to write to the backup bucket. A local machine can use an IAM role, a short-lived credential or a dedicated user with a rotated key. Record the run time, commit identifier, object key and result in a log the site owner can check.

Restore regularly and preserve the archive

A backup becomes useful only when someone can restore it. Once a month, select a recent copy, rebuild the site in a clean environment and compare the output with the live version. Also attempt a full recovery in a separate folder or staging host. Check images, internal links, redirects, forms and the certificate, then record any differences instead of assuming success because a command returned zero.

Keep the evidence needed to rebuild by hand. Git history, build instructions, dependency versions, DNS notes and registrar access details should travel with the archives. For domains, confirm the authoritative nameservers, renewal date and responsible contact; for a .com.au domain, include the registry or reseller reference that supports transfer if the original account disappears.

Web archives add another kind of continuity. A preserved Australian online pokies coverage can document community history and the state of a page at a particular moment, even if the live site later changes. Such captures complement file-level backups because they preserve what readers saw rather than merely what a build server stored. Keep their provenance and capture dates alongside the original content.

Adopt a backup policy that fits

The strongest routine is one a volunteer or small team can actually maintain. Agree on the files, storage locations, schedule, retention period, responsible person and restore test, then write it down in plain language. “Set it, check it, move on” is a fair dinkum approach to infrastructure: automation should remove repetitive work, not create another mystery.

Review retention when the project changes, but avoid deleting the only good copy before its replacement has been restored successfully. A daily copy for a year is inexpensive for a small site; an hourly archive of a large media library is a different budget conversation. Cloud storage in Australia is commonly sold by capacity with monthly fees, so include backup growth in the annual cost.

Start by protecting the source, then schedule one remote copy and test a restore before calling the job finished. If you already use continuous deployment, add the archive and retention steps to that workflow; if the site is maintained by hand, a scripted scheduled job can be enough. Most importantly, make ownership explicit: the person who can renew the domain should know where the backups, credentials and restoration notes live.

Create a one-page runbook today: list the source repository, backup bucket, schedule, retention and restore owner. Then run the first job and put the restore test in the shared calendar of your team or community group. The resource hub’s preserved pages offer a useful example of how older sections can remain navigable, while your own runbook records the modern path to recovery. Regular review keeps a modest, low-cost routine aligned with the way your community actually publishes.