WordPress-Multisite-Backup auf ScalaHosting

Multisite-Backup auf ScalaHosting richtig angehen

On ScalaHosting (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 ScalaHosting 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 ScalaHosting 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 ScalaHosting 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 ScalaHosting, 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 ScalaHosting

Before you trust a ScalaHosting 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 a job restarts at 0% on ScalaHosting, check locks, tmp cleanup, and whether a new job ID was created before re-running.

Aufbewahrung, Verschlüsselung und Support-Hygiene

For wordpress multisite backup on scalahosting, 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.

When opening a support ticket, include the last job log lines, hosting class, PHP limits, free disk, and whether a local archive already exists.