Introduction

Solid Backups Deployment allows you to easily push or pull a site's database, media files, plugins, and active theme back and forth between sites. This allows you to develop on one site and then push changes to another. Contents of the destination site (the site you are pushing to) will be overwritten as needed. During Deployment, you will be displayed a continuous status of the process and you will be given the opportunity to test the changes and undo the database changes before making them permanent.

• "Solid Backups Deployment" remote destination allows pushing or pulling your entire site to or from another existing site, in as few as two clicks.
• See differences in site server settings, active plugins, theme, versions, and media prior to deploying.
• Options to transfer the database (all tables, some, or none), plugins, theme, and/or media.
• Automatic migration of URLs, paths, and other settings just like manual migrations.
• Watch the deployment progress just like a normal backup, displaying a continuous status including a detailed advanced status log of the entire process, all in one place.
• Ability to undo the database changes with one click if something goes wrong prior to confirming the deployment once you're satisfied.
• Automatic chunking of data transferred between servers to support large files or slow servers.
• Swaps databases only after the entire database and all files have been transferred to attempt to minimize site downtime to mere seconds (or less!).
• Perfect for developing your site in a different location from the live site. Use staging best practices.

Setup

1. On the site you want to Push to or Pull from, go to the Backups > Destinations page then select the "Show Deployment Key" button at the top of the page.
   • If it is your first time setting up Deployment on this site you will be prompted to add the following line to the wp-config.php file (after doing so, refresh the page and select "Show Deployment Key" again to view the key):

     define( 'BACKUPBUDDY_API_ENABLE', true );

2. You will see a Deployment API Key that looks something like the following:

   eyJrZXlfdmVyc2lvbiI6MSwia2V5X3B1YmxpYyI6IjXiMzJmZjJmZjEzODhlOWRmNzA5YzFkY2NkYzNlMzY2Iiwia2V5X3NlY3JldCI6IjM5ZWM1NWE3YjJiZmY3OWIwYTAyOTNlZmYxMxODczIiwia2V5X2NyZWF0ZWQiOjE0MjExMTAwOTUsInNpdGV1cmwiOiJodHRwsdml84sC9iYWNrdXBidWRkeTIiLCJob21ldXJsIjoiaHR0cDpsdjc98wjDXXYaVwYnVkZHkyIn0=

3. Copy this key. You will enter this key on your other site.
4. On the site you want to Push from or Pull to go to the Backups > Destinations page and click the tab "+ Add New".
5. Select the "Solid Backups Deployment" destination.
6. Enter the API key you copied from the other site. You may test and add the destination now. The setup is now complete.

7. If needed, you can see how to edit the wp-config.php file in this article. 

Pushing & Pulling

1. Go to the site you wish to Push from or Pull to.st
2. Go to the Backups > Destinations page and select the tab for the Deployment destination you added during Setup.
3. Select "Push to" or "Pull from" depending on what you want to do.
4. You will be shown information about both sites and their server configuration including WordPress & plugin versions, media information, database tables, runtime details, and more.
5. Select what data you wish to transfer including Database tables, Media files, Plugins, and Theme files.
6. Click "Begin Deployment" to start the process.
7. You will be shown a status display giving an overview of the current progress including files transferred including a detailed Status Log.
8. Test the destination site to verify everything looks okay and then click "Confirm Deployment" to finalize these changes. If you do not confirm the changes within 12 hours they will be considered finalized. If you are not satisfied with the changes select "Undo Database Changes" to rollback to the database in place prior to the Deployment process.

Staging

Overview

• Staging is a method of developing your site at a different location than your Live site. It may consist of two or three separate sites at separate URLs. For instance, in the image to the right, you may have a local Development site, a remote Staging site, and a Live Production site.
• Example: You could develop your site locally on your computer for convenience, then Deploy it to the Staging/test site on the same server (but at a different URL) as the live site to ensure server compatibility, demo to clients, etc. Once satisfied you can then Push to the Production/Live site.
• Example: If you want to try out a major plugin update but you want to make sure it does not break the live site, you could go to your Development site and then Pull the Production site down. After verifying everything works as expected you could then either Push these changes back to the Production site or go directly to the Production site and update the plugin there.

Best Practices

• When Pushing and Pulling between sites it is important that you only send the contents you wish to overwrite on the destination site. For instance, you probably would not want to send the WordPress comments on your Development site to your Production site so comments would not be overwritten.
• Solid Backups does not "merge" database contents. Entire tables are either sent or not sent. You may do something similar to a merge by excluding one or more tables from being deployed. Tables not sent will result in the existing database table being left as-is.

Limitations

Overall

• At least one site must be able to access other URL. eg to Push, that destination URL must be accessible from the source computer.
• Only active theme files will be updated & both sites must have the same active theme at this time.
• Sites must have enough resources to be able to backup, restore, and make connections for sending files (eg via curl). Solid Backups should be fully operational for normal functionality before attempting Deployments.
• Modern mode is highly recommended (vs Classic Mode) for Deployment. Classic mode may result in timeouts or nesting level errors as Solid Backups must perform many loops for deployment.
• When transferring files, files that have been deleted on the other server may not be deleted remotely.
• When transferring files, empty directories will not be transferred.
• Windows support is currently experimental and not currently supported. Windows Deployment support is in progress.

Pulling

• The remote server is suggested to have an admin user with the same username as the local server. If it does not, a logout may occur on pulling server post-restore. We attempt to work around this but some setups may still result in a logout.

See also

• Local Development