WordPress-Multisite-Backup auf ALL-INKL

Multisite-Backup auf ALL-INKL richtig angehen

On ALL-INKL (shared hosting), a WordPress Multisite backup is more than copying wp-content. You need shared core files, network tables, per-site tables, and uploads under sites/ — or restore will miss users, settings, or media. PHP max_execution_time and memory ceilings are often tight on shared plans.

Multisite Migrate runs chunked, resumable jobs from Network Admin (full network) or from a subsite dashboard when the role has manage_options. Free covers core network/subsite backup and restore plus one local schedule. Plus adds BYO cloud upload (Google Drive, Dropbox, S3-compatible, SFTP) and cloud schedules. Pro adds remote import, empty-server installer, Staging, WP-CLI, and network split. Inode and tmp-disk limits can abort oversized archives mid-job.

Was ein vollständiges Multisite-Backup auf ALL-INKL enthalten muss

Capture the network tables (wp_blogs, wp_site, wp_sitemeta, and related), each subsite’s tables, shared themes/plugins, and the sites/ upload tree. Skipping any of those on ALL-INKL creates “successful” archives that still fail a real restore drill. Exclude cache, tmp, and other regenerable noise so jobs finish faster on shared plans.

WordPress cron may be delayed unless a real system cron hits wp-cron.php. Treat provider snapshots as an extra layer — not a Multisite-scoped import workflow. Keep a plugin archive you can move, import, and verify independently of the ALL-INKL control panel.

So führt Multisite Migrate Jobs auf dieser Host-Klasse aus

Shared and managed hosts often kill long PHP workers. Multisite Migrate therefore uses Jobs in Chunks that resume instead of restarting from zero after a timeout. On ALL-INKL, start from Network Admin for fleet backups, or from a single site when a subsite admin only needs their site. Watch the job log for the last completed chunk, disk/inode warnings, and cloud auth errors on Plus.

For schedules: Free keeps one local schedule; Plus can push finished archives to Drive, Dropbox, S3-compatible storage, or SFTP. Wasabi, Backblaze B2, Cloudflare R2, DigitalOcean Spaces, and MinIO are S3-compatible endpoints — not separate proprietary vaults. OneDrive is not a native destination.

Restore-Drill-Checkliste für ALL-INKL

Before you trust a ALL-INKL backup routine, restore once on Staging (or a throwaway site): check siteurl/home, HTTPS, domain mapping (sunrise.php if used), media under sites/, logins, and any WooCommerce or membership data. Confirm rewrite rules and purge CDN/object-cache drop-ins if the front end still shows stale content.

If import fails on ALL-INKL, raise upload_max_filesize and post_max_size only as far as needed, free disk, then retry with chunked resume.

Aufbewahrung, Verschlüsselung und Support-Hygiene

For wordpress multisite backup on all-inkl, keep enough archive generations to roll back a bad deploy or failed migration. Optional .venc AES-256 encryption on Multisite Migrate archives protects copies at rest when you store offsite on Plus destinations. Document credentials, schedule windows, and who may run Network Admin jobs.

Separate schedule failures from restore failures in your runbook so on-call staff do not rebuild a finished archive unnecessarily.