Digipacket Backup Toolkit

What it does

Shared hosting kills long requests, so every operation is cut into slices that fit inside max_execution_time and resume where they stopped — the file scan, the SQL dump, the compression, the encryption, the extraction and the row-by-row replay of the database. It makes no outbound connection and has no telemetry.

• Full site or one part

  Whole site, database only, wp-content, plugins, themes or uploads, with the size, duration and checksum reported as it runs.

• Restore with a rollback

  A safety snapshot is taken before a byte is written, and a failure half way through rolls the site back to it automatically.

• AES-256-GCM

  Over the whole container, with a keyring that survives rotation. Existing archives can be sealed afterwards and sealed ones opened.

• Scheduled runs

  Hourly to monthly or a custom cron expression, with retention by count or by age. Deleting a schedule never deletes its backups.

• Imports are verified, not trusted

  Signature, checksums, manifest, directory traversal, Zip Slip and symbolic links are all checked before an entry is published.

• Archives outside the plugin folder

  They live in wp-content/digipacket-backups/, because WordPress deletes a plugin's own folder before installing a new version.

What it needs

WordPress

6.8 or newer

PHP

8.2 or newer

PHP extensions

json, zip, hash, openssl

Install it

cd /path/to/wordpress/wp-content/plugins \
  && curl -fL -O https://github.com/digipacket-net/Digipacket-Backup-Toolkit/releases/download/V2.0.1/digipacket.2.0.1.zip \
  && echo "e1b920b3161d70721d00abf63990268708d1e40451863546176db7a4bfb286c8  digipacket.2.0.1.zip" | sha256sum -c - \
  && unzip -q digipacket.2.0.1.zip \
  && rm digipacket.2.0.1.zip

wp plugin activate digipacket --path=/path/to/wordpress

Why the commands look like this

• Why -f is not optional

  Without it, curl writes the server's error page into your file and exits 0. You unzip an HTML document into wp-content/plugins and WordPress shows a broken plugin. With -f, curl writes nothing and exits 22.

• Why the checksum is printed here

  A hash served next to the file only proves the download was not corrupted in transit. This page is a second channel: if the number here and the number on the file agree, both would have had to be changed.

• Why the steps are chained with &&

  A semicolon runs the next command whether or not the last one worked. With &&, a failed download or a failed checksum stops the chain before anything is written into your plugins directory.

Verify the download

# GNU coreutils, on a Linux server
echo "e1b920b3161d70721d00abf63990268708d1e40451863546176db7a4bfb286c8  digipacket.2.0.1.zip" | sha256sum -c -

# macOS, and anywhere sha256sum is missing
echo "e1b920b3161d70721d00abf63990268708d1e40451863546176db7a4bfb286c8  digipacket.2.0.1.zip" | shasum -a 256 -c

Always the newest release

The pinned URL above is the one to use in documentation and in a change you want to be able to repeat. In a provisioning script you usually want whatever is current, and there is a trap in the obvious way of asking for it.

Ask the API which asset the latest release actually publishes, then download that:

url=$(curl -fsSL https://api.github.com/repos/digipacket-net/Digipacket-Backup-Toolkit/releases/latest \
  | grep -o '"browser_download_url": *"[^"]*\.zip"' \
  | cut -d'"' -f4)

curl -fL -O "$url"

Update it

Removing the folder first is safe: archives live in wp-content/digipacket-backups/ and settings live in the database, neither of which is inside the plugin directory.

cd /path/to/wordpress/wp-content/plugins \
  && curl -fL -O https://github.com/digipacket-net/Digipacket-Backup-Toolkit/releases/download/V2.0.1/digipacket.2.0.1.zip \
  && echo "e1b920b3161d70721d00abf63990268708d1e40451863546176db7a4bfb286c8  digipacket.2.0.1.zip" | sha256sum -c - \
  && rm -rf digipacket \
  && unzip -q digipacket.2.0.1.zip \
  && rm digipacket.2.0.1.zip \
  && wp plugin activate digipacket --path=/path/to/wordpress

Remove it

wp plugin deactivate digipacket --path=/path/to/wordpress \
  && wp plugin delete digipacket --path=/path/to/wordpress

What it does not do

Written down for the same reason as everything else on this page: finding out after you have installed it is worse.

• No export to Google Drive, Dropbox, S3 or OneDrive yet.
• No incremental backups — every run produces a complete archive.
• Nginx ignores the .htaccess written at activation, so on Nginx the equivalent rule for the backups directory has to be added by hand.

If a command fails