by
Digipacket
1 (0 reviews)
Digipacket Backup Toolkit
Back up, restore, import and encrypt your WordPress site. Resumable on any host, AES-256-GCM sealed, and nothing leaves your server.
Digipacket Backup Toolkit ranks #67,865 among WordPress.org plugins with 1+ active installations, is #3,537 of 4,988 in the Utilities & Tools category, a 1/5 rating from 0 reviews, and was last updated Aug 16, 2026. Data from WordPress.org, refreshed twice daily — see methodology.
Tested up to WP 7 (Current: 7.1.2)
v2.0.1
Current Version v2.0.1
Updated 1 month ago
Last Update on 16 Aug, 2026
Refreshed 8 hours ago
Last Refreshed on
#3,537 of 4,988 in Utilities & Tools
Rank
#67,865
—
No change
Active Installs
1+
—
No change
KW Avg Position
125
22 better
Downloads
118
+4 today
Support Resolved
0%
—
No change
Rating
20%
Review 1 out of 5
1
(0 reviews)
Next Milestone 10
0+
10+
66,919
Ranks to Climb
-
Growth Needed
8,000,000
Active Installs
Pro
Unlock Exact Install Count
See the precise estimated active installs for this plugin, calculated from real-time ranking data.
- Exact install estimates within tiers
- Track install growth over time
- Milestone progress predictions
Need 9 more installs to reach 10+
Rank Changes
Current
#67,865
Change
Best
#
Downloads Growth
Downloads
Growth
Peak
Upgrade to Pro
Unlock 30-day, 90-day, and yearly download history charts with a Pro subscription.
Upgrade NowReviews & Ratings
1.0
0 reviews
Overall
20%
5
0
(0%)
4
0
(0%)
3
0
(0%)
2
0
(0%)
1
0
(0%)
Track This Plugin
Get detailed analytics, keyword tracking, and position alerts delivered to your inbox.
Start Tracking FreePlugin Details
- Version
- 2.0.1
- Last Updated
- Aug 16, 2026
- Requires WP
- 6.8+
- Tested Up To
- 7
- PHP Version
- 8.2 or higher
- Author
- Digipacket
Support & Rating
- Rating
- ★ ☆ ☆ ☆ ☆ 1
- Reviews
- 0
- Support Threads
- 0
- Resolved
- 0%
Keywords
Upgrade to Pro
Unlock keyword rankings, search positions, and detailed analytics with a Pro subscription.
Upgrade NowSimilar Plugins
Adminify – White Label, Admin Menu Editor, Login Customizer
6K+ installs
#2,758
Master Addons for Elementor – Elementor Addons, Widgets, Mega Menu Builder, Popup Builder, Widget Builder & Template Kits
30K+ installs
#1,008
Elementor Website Builder - more than just a page builder
10M+ installs
#1
Contact Form 7
10M+ installs
#3
All-in-One WP Migration and Backup
5M+ installs
#10
UpdraftPlus: WP Backup & Migration Plugin
3M+ installs
#15
WPCode - Insert Headers and Footers + Custom Code Snippets - WordPress Code Manager
3M+ installs
#19
Hostinger Tools
3M+ installs
#20
WordPress Importer
2M+ installs
#23
WPS Hide Login
2M+ installs
#27
Frequently Asked Questions
Common questions about Digipacket Backup Toolkit
No. The plugin makes no outbound connection of any kind. Your archives stay on your server until you download them yourself. The task says Active, the hour has passed, and nothing ran. 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 always the one on your wall.
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
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 can reach the archives.
That is what it is designed for. Every long operation resumes across requests, so a 30 second max_execution_time is enough.
