Hello! I’m having an issue exporting a database using wp-cli from my local development server to a remote staging server.
I’ve run vagrant ssh, and am in the /srv/www/{mysite.com}/current folder - i’m trying to run: wp db export --ssh=root@vas.mysite.com.au /srv/www/mysite.com.au/current/
but it’s returning the following error: Error: This does not seem to be a WordPress install. Pass --path=`path/to/wordpress` or run `wp core download`.
I’m able to successfully run other wp-cli commands like wp db check which returns green across the board.
I’m just trying to export my local database to my remote staging server. I assume that once it’s exported the remote location above, I should just be able to run wb db import mysite_dbase.sql?
wp db export
rsync -azP /srv/www/{mysite.com}/current/mysite_com_development.sql root@vas.mysite.com.au:/srv/www/mysite.com.au/current/
Then just hop on the other server and import like you said.
But realistically you should run the rsync with your web user instead of root on the remote server, so that the file will have the proper permissions for the import and not be owned by root in your web folder.
Normally I just export my database inside my local root directory and just rsync the whole current/ folder to the remote server. Rsync will only move files that have changed as well after the first time, so it gets much faster the next couple go rounds.
I also found the shell script @ben posted up made loads of sense. I tweaked it a bit for my liking and I use it for pushing the database and uploads from dev up to staging:
read -r -p "Would you really like to overwrite the staging database with dev? [y/N] " response
if [[ $response =~ ^([yY][eE][sS]|[yY])$ ]]
then
wp @development db export - > sql-dump-development.sql
scp sql-dump-development.sql web@staging.example.com:/srv/www/example.com/current
wp @staging db export just-in-case.sql
wp @staging db reset --yes
wp @staging db import sql-dump-development.sql
wp @staging search-replace https://example.dev https://staging.example.com
rm sql-dump-development.sql
ssh web@staging.example.com 'rm /srv/www/example.com/current/sql-dump-development.sql'
read -r -p "Did everything run smoothly? Remove the temp backup sql file? [y/N] " response
if [[ $response =~ ^([yY][eE][sS]|[yY])$ ]]
then
ssh web@staging.example.com 'rm /srv/www/example.com/current/just-in-case.sql'
fi
read -r -p "Sync uploads from dev to staging? [y/N] " response
if [[ $response =~ ^([yY][eE][sS]|[yY])$ ]]
then
scp -r web/app/uploads/ web@staging.example.com:/srv/www/example.com/shared
fi
else
exit 0
fi
Could be improved I’m sure but works for me at the moment!
Hi @RiFi2k - thanks for your responses! I’ll give the one-two step process a shot - yep I’m running the command after i’ve ssh’d into my local vagrant server.
The shell script is cool, its basically doing the same thing just saving you from having to ssh into the server yourself. I’m pretty much always logged in to every server I have anyways.
I actually use https://github.com/c9/core installed in the web root of my servers running under the web user. I run a proxy pass in nginx from localhost to a configured URL running under Cloudflare forced SSL, restricting access by IP and also using basic auth. Been running it this way for close to 8 months, super secure, never had a problem, and I get a full code editor, command line access, and ability to make edits and drag and drop files and folders right in my web root, with the web user as pilot, anytime I want. It’s probably the best thing (other than Trellis) that I have found to make my life easier in years. Game changer once its set up.
Thanks for the rsync tip @RiFi2k - worked like a charm, just exported the database locally, rsynced to the remote server, imported it, ran a search and replace dry test on the domain name, then ran the actual search and replace, then removed the sql file. Fastest and most pain free database sync I’ve ever had the pleasure of doing.
Edit: Would be awesome if this process could be some kind of flag option we could add to the standard deploy command like ./bin/deploy.sh <server> <domain.com> --sync-database - not sure how that would work though
For sure, for me though, I think you can over automate, then you don’t actually know what needs to be done if your scripts and automation break or fail. I actually enjoy and feel better overall when I’m running the migrations server to server myself.
