Optimizing Server Configuration for WordPress Backup Performance

Content Delivery Networks (CDNs) dramatically improve WordPress site speed by serving images, CSS, and JavaScript from globally distributed servers. But CDNs add complexity to backups and restoration—URLs change, assets live on external servers, and migrations require careful URL replacement to avoid broken images and missing files.

This comprehensive guide tackles the unique challenges CDNs create for WordPress backups. You’ll learn how CDN URL structures affect database backups, how to properly backup and restore CDN-enabled sites, and how to handle migrations without breaking asset links. Whether you use Cloudflare, MaxCDN, Amazon CloudFront, or another provider, you’ll understand exactly how to maintain bulletproof backups.

By the end of this tutorial, you’ll know how to backup CDN-configured sites correctly, restore them without broken assets, and test backups while preserving CDN functionality.

Understanding CDNs and WordPress

What is a CDN?

Traditional WordPress Hosting:

User in Australia → Server in USA → Slow (200ms+ latency)

With CDN:

User in Australia → CDN Edge Server in Sydney → Fast (20ms latency)
User in USA → CDN Edge Server in New York → Fast (15ms latency)

How CDNs Work:

1. WordPress uploads image to server: yoursite.com/uploads/logo.png
2. CDN plugin rewrites URL: cdn.yoursite.com/uploads/logo.png
3. User requests image from CDN subdomain
4. CDN serves cached copy from nearest server
5. Fast delivery, reduced server load

Popular CDN Providers

Cloudflare (Most Popular):

• Free tier available
• Automatic SSL
• DDoS protection included
• DNS-based (proxies entire site)
• 275+ edge locations worldwide

StackPath (formerly MaxCDN):

• Pull CDN (caches on-demand)
• Custom CDN URLs
• Real-time cache purging
• Starting $10/month

Amazon CloudFront:

• AWS integration
• Pay-as-you-go pricing
• Global edge network
• Complex configuration

KeyCDN:

• Budget-friendly ($0.04/GB)
• Simple setup
• HTTP/2 support
• 34 edge locations

BunnyCDN:

• Very affordable ($0.01/GB)
• Fast performance
• WordPress plugin available
• 91 edge locations

CDN URL Structures

Subdomain CDN:

Original: https://yoursite.com/wp-content/uploads/image.jpg
CDN:      https://cdn.yoursite.com/wp-content/uploads/image.jpg

Custom Domain:

Original: https://yoursite.com/wp-content/uploads/image.jpg
CDN:      https://static.yoursite.com/wp-content/uploads/image.jpg

Third-Party Domain:

Original: https://yoursite.com/wp-content/uploads/image.jpg
CDN:      https://d3abc123xyz.cloudfront.net/wp-content/uploads/image.jpg

Cloudflare (Transparent):

Original: https://yoursite.com/wp-content/uploads/image.jpg
CDN:      https://yoursite.com/wp-content/uploads/image.jpg (same URL!)

How CDNs Affect WordPress Backups

Database URL Rewriting

Problem: CDN plugins rewrite URLs in database:

wp_posts table (post content):

<!-- Original -->
<img src="https://yoursite.com/uploads/photo.jpg">

<!-- After CDN activation -->
<img src="https://cdn.yoursite.com/uploads/photo.jpg">

Backup Impact:

• Database contains CDN URLs
• Restoring to new domain keeps old CDN references
• Broken images if CDN subdomain doesn’t exist on new site

Asset Location Confusion

CDN serves files from origin server:

• Files still physically on WordPress server: /wp-content/uploads/
• CDN caches copies on edge servers
• Backup includes original files (good!)
• But database references CDN URLs (problematic)

Restore Scenario:

Backup from: yoursite.com (using cdn.yoursite.com)
Restore to: newsite.com

Problem: Database has cdn.yoursite.com URLs
Files exist at: newsite.com/wp-content/uploads/
Result: Broken images (looking for cdn.yoursite.com instead of newsite.com)

Cache Invalidation After Restore

Restoring from backup = stale CDN cache:

Example:

1. Site has logo-v1.png cached on CDN
2. You restore backup from 2 weeks ago with logo-v2.png
3. CDN still serves cached logo-v1.png
4. Site shows wrong logo until cache expires or manual purge

Backing Up CDN-Enabled Sites

What to Include in Backups

Database:

• Contains CDN-rewritten URLs
• Backup as-is (with CDN URLs)
• Will search-replace during restoration

Files:

• /wp-content/uploads/ – All media files (CDN source)
• /wp-content/themes/ – Themes (may reference CDN)
• /wp-content/plugins/ – CDN plugins and configuration
• wp-config.php – May contain CDN constants

CDN Configuration:

• Document CDN provider settings
• Note subdomain/custom domain
• Record CDN zones/distributions
• Save plugin settings (screenshot or export)

Backup Best Practices with CDN

1. Include CDN Plugin Settings:

Many CDN plugins store config in wp_options:

SELECT * FROM wp_options
WHERE option_name LIKE '%cdn%' OR option_name LIKE '%cloudflare%';

Backup includes this automatically.

2. Document CDN Setup:

Create cdn-config.txt with:

CDN Provider: Cloudflare
CDN URL: yoursite.com (proxied)
Plugin: Cloudflare Official Plugin
API Token: [stored in wp_options]
Cache Settings: Browser cache 4 hours, edge cache 30 days
Page Rules: Cache everything on /wp-content/*

Alternative access (if CDN down): origin.yoursite.com

3. Test Backup Without CDN:

Before creating backup:

1. Temporarily disable CDN plugin
2. Verify site works with local assets
3. If yes, CDN is non-essential layer
4. Create backup
5. Re-enable CDN

This proves backup is self-contained.

Find-Replace Strategies for CDN URLs

Identifying CDN URLs in Backup

Search backup SQL file for CDN patterns:

# Linux/Mac
grep -i "cdn\." backup.sql | head -20

# Windows (PowerShell)
Select-String -Path backup.sql -Pattern "cdn\." | Select-Object -First 20

Common patterns:

• cdn.yoursite.com
• static.yoursite.com
• d3abc123xyz.cloudfront.net
• yoursite-cdn.stackpathcdn.com

Search-Replace During Restoration

Using WP-CLI:

# Replace CDN subdomain with new domain
wp search-replace 'cdn.oldsite.com' 'newsite.com' --all-tables

# Replace CloudFront URL with new domain
wp search-replace 'd3abc123xyz.cloudfront.net' 'newsite.com' --all-tables

# Replace old domain with new domain (catches non-CDN URLs too)
wp search-replace 'oldsite.com' 'newsite.com' --all-tables

Using Better Search Replace plugin:

1. Install Better Search Replace
2. Search for: cdn.oldsite.com
3. Replace with: newsite.com
4. Select all tables
5. Run (uncheck “dry run” after testing)

Backup Copilot Pro Find-Replace:

1. During restoration, enable “Find & Replace URLs”
2. Old URL: https://cdn.oldsite.com
3. New URL: https://newsite.com
4. Plugin updates all database references automatically

Multiple CDN URL Patterns

Complex scenario: Site uses multiple CDN URLs:

• Images: cdn.yoursite.com
• CSS/JS: static.yoursite.com
• Videos: d3abc123xyz.cloudfront.net

Solution: Multiple search-replace operations:

wp search-replace 'cdn.yoursite.com' 'newsite.com' --all-tables
wp search-replace 'static.yoursite.com' 'newsite.com' --all-tables
wp search-replace 'd3abc123xyz.cloudfront.net' 'newsite.com' --all-tables

Run sequentially to replace all CDN patterns.

Provider-Specific Backup Considerations

Cloudflare

Unique Characteristics:

• DNS-based proxy (transparent to WordPress)
• URLs don’t change in database (no rewriting!)
• Caches entire site, not just assets
• Page Rules affect dynamic content

Backup Simplicity: Cloudflare is easiest for backups:

• Database has normal URLs (no CDN subdomain)
• Restore to new domain = change WordPress site URL
• No CDN URL find-replace needed
• Just update Cloudflare DNS to point to new server

Post-Restore Steps:

1. Restore backup to new server
2. Update Cloudflare DNS A record to new server IP
3. Purge Cloudflare cache: Performance > Purge Everything
4. Test site loads correctly
5. Done!

Development Mode:

• Enable Cloudflare > Caching > Development Mode
• Bypasses cache for 3 hours
• Useful when testing restored site

MaxCDN / StackPath

Characteristics:

• Pull CDN with custom subdomain
• Plugin rewrites URLs in database
• Separate CDN zone configuration

Backup Challenge: Database contains yoursite-cdn.stackpathcdn.com URLs.

Restoration Process:

1. Restore backup to new site
2. Install StackPath plugin
3. Create new CDN zone (or keep old one)
4. Run search-replace:
   • Old: yoursite-cdn.stackpathcdn.com
   • New: newsite.com (if not using CDN) or newsite-cdn.stackpathcdn.com
5. Purge StackPath cache from dashboard

Alternative: Keep Same CDN Zone: If migrating to new domain but keeping CDN:

1. Update origin server in StackPath dashboard
2. Point to new server IP
3. Keep CDN URLs unchanged in database
4. No search-replace needed

Amazon CloudFront

Characteristics:

• Most complex setup
• Unique distribution URLs (d3abc123xyz.cloudfront.net)
• Requires AWS console management

Backup Challenge: Database full of CloudFront URLs.

Restoration Options:

Option A: Disable CDN on Restored Site

# Replace CloudFront URLs with new domain
wp search-replace 'd3abc123xyz.cloudfront.net' 'newsite.com' --all-tables

Option B: Create New CloudFront Distribution

1. Restore backup
2. Create new CloudFront distribution pointing to new site
3. Get new distribution URL (d3def456abc.cloudfront.net)
4. Search-replace old CloudFront → new CloudFront
5. Update DNS CNAMEs if using custom domain

Option C: Update Existing Distribution

1. Restore backup to new server
2. Update CloudFront origin to point to new server
3. Keep distribution URL unchanged
4. No database search-replace needed
5. Invalidate CloudFront cache

Restoring Sites with Active CDN

Pre-Restoration Checklist

1. Document Current CDN Setup:

• Provider name
• CDN URLs/subdomains
• Plugin settings
• DNS records (CNAME)

2. Decide CDN Strategy for Restored Site:

• Keep CDN active?
• Disable temporarily?
• Migrate to new CDN?

3. Prepare Search-Replace Plan:

• List all CDN URLs in database
• Determine replacement URLs
• Test find-replace on staging first

Step-by-Step Restoration Process

Scenario: Restoring to new domain with CDN disabled

1. Restore Database:
   • Import backup SQL to new database
   • Database contains old domain + CDN URLs
2. Restore Files:
   • Extract wp-content, wp-config.php
   • Files uploaded to new server
3. Update wp-config.php:
   • Update database credentials for new database
4. Search-Replace URLs:

# Replace old domain (non-CDN)
wp search-replace 'oldsite.com' 'newsite.com' --all-tables

# Replace CDN subdomain
wp search-replace 'cdn.oldsite.com' 'newsite.com' --all-tables

5. Deactivate CDN Plugin:

wp plugin deactivate cdn-enabler

6. Verify Assets Load:
   • Visit site, check images display
   • Inspect source code for CDN URLs
   • Should all be newsite.com
7. Test Functionality:
   • Forms submit
   • Pages load
   • Admin panel works

Scenario: Restoring with CDN active

1. Restore database and files (same as above)
2. Keep CDN plugin active
3. Update CDN configuration in plugin settings:
   • CDN URL: Update to new CDN subdomain or keep old
   • Origin: Update to new server
4. Update CDN provider dashboard:
   • Point origin to new server IP
5. Purge CDN cache
6. Test site loads with CDN serving assets

Troubleshooting CDN Backup Issues

Broken Assets After Restoration

Symptom:

• Site loads but images show broken
• CSS/JS not loading
• Mixed content warnings

Diagnosis: View page source, check image URLs:

<!-- Problem: Still referencing old CDN -->
<img src="https://cdn.oldsite.com/uploads/image.jpg">

Solution: Run search-replace to fix CDN URLs:

wp search-replace 'cdn.oldsite.com' 'newsite.com' --all-tables --dry-run
# Review output, then run without --dry-run
wp search-replace 'cdn.oldsite.com' 'newsite.com' --all-tables

Verify:

• Refresh page with cache cleared (Ctrl+Shift+R)
• Check source again
• Images should now load from newsite.com

Mixed Content Warnings (HTTP/HTTPS)

Problem:

• Restored site uses HTTPS (SSL)
• CDN URLs in database use HTTP
• Browser blocks HTTP content on HTTPS page

Example:

<!-- Page is HTTPS -->
<html>
<!-- Image is HTTP - blocked! -->
<img src="http://cdn.oldsite.com/uploads/photo.jpg">

Solution: Replace HTTP CDN URLs with HTTPS:

wp search-replace 'http://cdn.oldsite.com' 'https://newsite.com' --all-tables

Or use Really Simple SSL plugin to automatically convert.

CDN Cache Shows Old Content

Problem:

• Site restored from backup
• Old content still showing (from CDN cache)

Solution: Purge CDN cache:

Cloudflare:

1. Cloudflare dashboard
2. Caching > Purge Cache > Purge Everything

StackPath:

1. StackPath dashboard
2. Sites > yoursite > Purge
3. Purge All

CloudFront:

aws cloudfront create-invalidation \
  --distribution-id EDFDVBD6EXAMPLE \
  --paths "/*"

Or via AWS Console > CloudFront > Invalidations

After purging:

• Wait 5-10 minutes for purge to complete
• Clear browser cache
• Reload site
• Should show current content

CDN Subdomain DNS Not Resolving

Problem:

• Restored site references cdn.newsite.com
• DNS not configured for CDN subdomain
• Assets fail to load

Solution: Create DNS CNAME record:

Type: CNAME
Name: cdn
Value: newsite.com (or CDN provider URL)
TTL: 300

Or point directly to CDN provider:

Type: CNAME
Name: cdn
Value: newsite-cdn.stackpathcdn.com

Allow 5-60 minutes for DNS propagation.

Testing Backups with CDN Active

Staging Environment Setup

Best Practice: Test restores on staging subdomain

1. Create staging subdomain:
   • staging.yoursite.com
   • Separate from production
2. Restore backup to staging:
   • Import database
   • Upload files
3. Update URLs for staging:

wp search-replace 'yoursite.com' 'staging.yoursite.com' --all-tables
wp search-replace 'cdn.yoursite.com' 'staging.yoursite.com' --all-tables

4. Disable CDN on staging:

wp plugin deactivate cdn-enabler cloudflare

5. Test restoration:
   • Site loads correctly
   • All content accessible
   • No broken assets
6. Document process:
   • Note any issues encountered
   • Refine restoration procedure
   • Update disaster recovery plan

Automated Testing

WP-CLI script to test backup restoration:

#!/bin/bash
# backup-test.sh

# Variables
BACKUP_SQL="backup.sql"
BACKUP_ZIP="backup.zip"
DB_NAME="staging_db"

# Import database
wp db import $BACKUP_SQL --path=/var/www/staging

# Extract files
unzip -o $BACKUP_ZIP -d /var/www/staging/wp-content

# Search-replace URLs
wp search-replace 'yoursite.com' 'staging.yoursite.com' --all-tables --path=/var/www/staging
wp search-replace 'cdn.yoursite.com' 'staging.yoursite.com' --all-tables --path=/var/www/staging

# Verify site loads
curl -I https://staging.yoursite.com | grep "200 OK"

if [ $? -eq 0 ]; then
  echo "Backup restoration test: SUCCESS"
else
  echo "Backup restoration test: FAILED"
  exit 1
fi

Run monthly to verify backups are restorable.

Performance Optimization

Backup Speed with CDN

CDN doesn’t affect backup speed:

• Backups copy local files (not from CDN)
• Database contains CDN URLs (text, minimal size impact)
• Backup time same whether CDN active or not

CDN helps with backup downloads: If serving backup files via WordPress:

• Enable CDN caching for backup directory
• Users download from CDN edge servers
• Faster download speeds globally

Not recommended for security: Backups should be private, not CDN-cached.

Restore Speed Optimization

Disable CDN during restoration:

• Eliminates cache invalidation delays
• Immediate visibility of restored content
• Re-enable CDN after verification

Purge cache strategically: Instead of “Purge Everything,” purge specific paths:

/wp-content/uploads/*
/wp-content/themes/*
/wp-content/plugins/*

Preserves cache for unchanged content.

Best Practices Summary

Before Enabling CDN:

• Create baseline backup without CDN
• Document URLs before rewriting

With CDN Active:

• Backup regularly (CDN doesn’t eliminate need)
• Document CDN configuration
• Test restores on staging with CDN disabled

During Migration:

• Plan search-replace strategy
• Test on staging first
• Purge CDN cache after restoration

Ongoing:

• Monitor backup completion (CDN shouldn’t interfere)
• Update disaster recovery documentation with CDN steps
• Test restoration annually

Related Resources

1. Cloudflare WordPress Guide
2. CDN Best Practices
3. WordPress CDN Integration
4. Amazon CloudFront Documentation
5. CDN Performance Optimization

---

Running a CDN? Backup Copilot Pro handles CDN URLs automatically with smart find-replace. Backup and restore seamlessly, regardless of your CDN setup—try it free!