Digipacket Backup Toolkit

No. The plugin makes no outbound connection of any kind. Your archives stay on your server until you download them yourself.

Open Backup Toolkit → Scheduled Backups. If the screen says WP-Cron is not firing, that is the answer: WordPress only runs scheduled work when a request comes in, and it triggers that work through a request the server makes to itself. A local install, a firewall or an HTTP password blocks it, and nothing ever runs. The fix is a real cron. Add to wp-config.php: define('DISABLE_WP_CRON', true); then, every five minutes: curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null Check the timezone too. The Next run tile is written on the site’s clock, in Settings → General, which is not…

Two reasons, usually together. First, a new schedule fires one full interval after you create it — a daily task runs in 24 hours, not tonight. The Next run column tells you exactly when. Second, WP-Cron only wakes up when someone loads a page, so on a site with no traffic nothing happens until your next visit. For a dependable schedule, disable WP-Cron and call wp-cron.php from a real system cron.

Yes. Pick Every day or Every week, then fill Start at — and for a weekly one, tick the days. The hour is the one on your site’s clock, and it stays that hour when the clocks change. Leave it empty and the frequency behaves as a plain interval: a daily task created at 14:07 runs at 14:07 the next day.

The notice names the cause itself. The full account is in Backup Toolkit → Logs, journal schedule, and in the task’s own History — the ⋮ menu of its row. One cause looks like a failure but is not: if a backup was already running when the schedule fired — a manual one whose tab was closed keeps the engine busy for up to an hour — the task simply waits and starts on its own within minutes. It is not marked failed and its next run is not pushed to tomorrow.

The safety snapshot. Before a restore writes anything, the plugin takes a complete backup of the site as it stands, so a failure can be undone. It is a normal backup, marked “Safety copy” in the library. It is never deleted automatically — delete it yourself once you are satisfied the restore worked.

No, and neither can anyone else. That is what encryption means. The keyring in storage/keys/keyring.json opens the archives sealed on this site; back it up somewhere safe, or set a master password so an archive can travel to another site.

Yes. Import the archive on the other site, then restore it. If the archive is encrypted and the other site does not have your keyring, the import pauses and asks for the master password instead of failing.

No. Uninstalling removes nothing by default. There is a setting to opt into a full cleanup, and it is off unless you turn it on.

Nginx never reads .htaccess, so the guard the plugin writes has no effect there. Add this to your server { } block, before the generic location ~ \.php$ block, then reload with nginx -t && systemctl reload nginx: location ~* /wp-content/digipacket-backups/ { deny all; return 403; } If you moved the storage with the digipacket_wp_backup_storage_path filter, use your own path in that rule. Better still, point the filter at a directory outside the document root — /var/backups/digipacket/, readable and writable by the PHP user — and no web server rule is needed at all, because there is no URL…

That is what it is designed for. Every long operation resumes across requests, so a 30 second max_execution_time is enough.

Ask in the support forum here, or write to us directly at https://dynetwork.net/contact.php — the link is on the plugins list and on the Logs screen. If something failed, send the records from Backup Toolkit → Logs with it: that file is what explains a failure after the fact.