You can back up and restore specific environments at any time using a snapshot. Snapshot options are available for all Starter environments and Pro Integration environments. The snapshot feature does not apply to the Pro Staging and Production environments.
The Pro Staging and Production environments receive regular backups for disaster recovery purposes by default, see Pro Backup & Disaster Recovery. However, these backups are not publicly accessible because they are stored in a separate system. You can open a ticket to request a backup with a specific date, time, and timezone. Then we can extract it from the external system and provide it to you.
Snapshots for Starter and Pro Integration environments are different from Pro backup and disaster recovery backups. Snapshots are not automatic. It is your responsibility to manually create a snapshot or set up a cron job to periodically take snapshots of your Starter or Pro Integration environments.
A snapshot is a complete backup of an environment that includes all persistent data from all running services (for example, your MySQL database, Redis, and so on) and any files stored on the mounted volumes. Because an environment deploys as a read-only file system, restoring a snapshot is fast.
If you want to roll back to previous code or remove added extensions in an environment, restoring a snapshot is not the recommended method. See Rollbacks to remove code. If you must restore an unstable environment that does not have a snapshot, see Restore an environment.
You have up to seven days to restore a snapshot.
Adobe provides two methods for creating and managing snapshots:
To create a snapshot using the Project Web Interface:
To create a snapshot using the magento-cloud
CLI:
Open a terminal and navigate to your project.
Check out the environment branch to snapshot.
Create the snapshot.
magento-cloud snapshot:create
Creating a snapshot of production
Waiting for the snapshot to complete...
The following modifiers further specify how to create the snapshot:
-p, --project=PROJECT The project ID
-e, --environment=ENVIRONMENT The environment ID
For a full list of options, enter magento-cloud snapshot:create --help
.
Verify the most recent snapshots.
magento-cloud snapshots
The list returns information about the snapshot status:
Finding snapshots for the environment <environment_name>
+---------------------------+--------------------+----------+----------+---------+
| Created | Snapshot name | Progress | State | Result |
+---------------------------+--------------------+----------+----------+---------+
| 2018-04-09T14:43:39-05:00 | <snapshot_ID>. | 100% | complete | success |
+---------------------------+--------------------+----------+----------+---------+
To restore a snapshot using the Project Web Interface:
To restore a snapshot using the Cloud CLI:
Open a terminal and navigate to your project.
Check out the environment branch to restore.
List all available snapshots.
magento-cloud snapshot:list
The list returns information about the available snapshots:
Finding snapshots for the environment <environment_name>
+---------------------------+--------------------+----------+----------+---------+
| Created | Snapshot name | Progress | State | Result |
+---------------------------+--------------------+----------+----------+---------+
| 2018-04-09T14:43:39-05:00 | <snapshot_ID>. | 100% | complete | success |
+---------------------------+--------------------+----------+----------+---------+
Restore a snapshot using the snapshot ID from the list.
magento-cloud snapshot:restore <snapshot-id>
The following modifiers further specify how to restore the snapshot:
-p, --project=PROJECT The project ID
-e, --environment=ENVIRONMENT The environment ID
You can create a copy of your database using the ece-tools db-dump
command. By default, this command creates backups in the /app/var/dump-main
directory for all database connections that are specified in the environment configuration. For example, if you configured your project to use split databases, the db-dump
operation creates backups for each of the configured databases.
You can choose to back up selected databases by appending the database names to the command, for example:
php vendor/bin/ece-tools db-dump -- main sales
Consider the following guidelines:
db-dump
command creates an archive in your remote project directory called dump-<timestamp>.sql.gz
.var/log/cloud.log
).var/dbdump.lock
file to prevent the command from running on more than one node.For help, use: php vendor/bin/ece-tools db-dump --help
To create a database dump in the Staging or Production environment:
Use SSH to log in to the remote environment that contains the database to copy.
Create a backup of the database. To choose a target directory for the DB dump, use the --dump-directory
option.
php vendor/bin/ece-tools db-dump
Sample response:
The db-dump operation switches the site to maintenance mode, stops all active cron jobs and consumer queue processes, and disables cron jobs before starting the dump process.
Your site will not receive any traffic until the operation completes.
Do you wish to proceed with this process? (y/N)? y
2020-01-28 16:38:08] INFO: Starting backup.
[2020-01-28 16:38:08] NOTICE: Enabling Maintenance mode
[2020-01-28 16:38:10] INFO: Trying to kill running cron jobs and consumers processes
[2020-01-28 16:38:10] INFO: Running Magento cron and consumers processes were not found.
[2020-01-28 16:38:10] INFO: Waiting for lock on db dump.
[2020-01-28 16:38:10] INFO: Start creation DB dump for main database...
[2020-01-28 16:38:10] INFO: Finished DB dump for main database, it can be found here: /tmp/qxmtlseakof6y/dump-main-1580229490.sql.gz
[2020-01-28 16:38:10] INFO: Backup completed.
[2020-01-28 16:38:11] NOTICE: Maintenance mode is disabled.
If you want to push this data into an environment, see Migrate data and static files.
Adobe recommends creating a snapshot of the environment and a backup of the database before deployments.
If you must restore a snapshot specifically to remove new code and added extensions, the process can be complicated depending on the number of changes and when you roll back. Some rollbacks might require database changes.
Specifically for code, you should investigate reverting code changes from your branch before redeploying. If not, every deploy pushes the master
branch (code and extensions) to the target environment again. See the Deployment Process.