Backup and Forget
Crell
Thu, 12/28/2020 – 20:59
Blog
Platform.sh allows users to create a byte-for-byte snapshot of any running environment, production or otherwise, at any time with a single button click or command line directive. That’s great for one off use, like preparing to deploy a new version or run some large batch process, but what about for routine disaster recovery backups? Can we do those?
Believe it or, not, it’s possible to automate yourself! And it’s only a 3 step process.
The basic idea is that the Platform.sh CLI can be triggered from any automation tool you’d like… including cron from within the application container. It just needs an authentication token available in the environment.
Step 1: Get a token
Create an authentication token for your user or a dedicated automation user. That’s easily done through the UI.
Set that token as a variable on your project, like so:
platform project:variable:set env:PLATFORMSH_CLI_TOKEN <value>
Step 2: Install the CLI
The Platform.sh CLI can be installed as part of a build hook within your project. Simply add the following line to your build hook:
curl -sS https://platform.sh/cli/installer | php
Now the CLI will be available in cron hooks, the deploy hook, or when logging in via SSH. It will use the token you provided a moment ago, and will automatically pick up the project and environment name from the existing environment variables.
Step 3: Snapshot on cron
You can now add a new cron entry to your .platform.app.yaml file, like so:
crons: snapshot: spec: ‘0 5 * * *’ cmd: | if [ “$PLATFORM_BRANCH” = master ]; then platform snapshot:create –yes –no-wait fi
That will run the cmd once a day at 5 am UTC. (Adjust for whenever low-traffic time is for your site.) Then if and only if it’s running on the master environment (production), the platform snapshot:create command will run and trigger a snapshot, just as if you’d run the command yourself. Poof, done.
Of note, though, are the –yes –no-wait flags. The first skips any user-interaction, since the command is running from cron. The second is extra important, as it tells cron to not block on the snapshot being created. If you forget that, cron will block on the snapshot which means so will any deploy you happen to try and trigger. That can result in extra-long deploys and site downtime. You don’t want that, we don’t want that, so make sure not include –no-wait.
That’s it that’s all, you’re done! Rejoice in daily automated backups of your production environment.
Larry Garfield
3 Jan, 2020
Source: New feed
