Faster cloning and migration
By default, cloning and migrating are already fast, and they run some safety checks
first. If you're doing a lot of these — say a bulk of copies — you can turn on two
optional switches that trade a little safety, or a little convenience, for speed.
These are small control files you create in your own shell (or over SFTP). They live
under your account's static/control/ folder, and creating one is all it takes —
the file's contents don't matter.
You don't need these for everyday use. Reach for them only if the default speed isn't enough for what you're doing. Everything else about the two tasks — what Clone and Migrate each do, and the safe way to use them — is on Cloning and moving a site.
FastTrack — skip the pre-flight checks
Before each clone or migrate, the system normally verifies the site and the platforms involved, to catch problems before they can break the job. That's the safe default, and it's what you want for a one-off.
If you're running many clones or migrates back to back and don't want those checks repeated every single time, create this file:
~/static/control/FastTrack.info
With it in place, the site and platform verifications are skipped, so each job starts sooner — and it also skips the extra re-verify that normally runs automatically after you import a platform. The trade-off is real: those checks exist to catch a broken setting or a missing module early, before it can leave a copy half-built. Skip them only when you've already confirmed everything is healthy and you're doing this in bulk.
To go back to the safe default, deleting FastTrack.info on its own isn't enough —
you also create an empty ClassicTrack.info to switch the pre-flight checks back on.
Two steps, in your shell:
touch ~/static/control/ClassicTrack.info
rm ~/static/control/FastTrack.info
The ClassicTrack.info file is what restores the "verify first" behaviour; the
system treats it as the on-switch for those extra checks.
MyQuick — parallel database copy
By default, the system already uses a fast, parallel per-table method to copy your database during clone and migrate — so large, complex databases finish in minutes rather than hours. This is on for you out of the box, and there's nothing to switch on.
There's one thing to be aware of. The fast method stores the database as a set of per-table files rather than the single-file dump the control panel's Restore task reads. Every backup you ask for — from the panel, over the API, or on the nightly schedule — now carries that single-file dump anyway, because the Backup task fills in the full mode whenever one wasn't chosen. What stays dump-less is the automatic copies Clone, Migrate and Delete take for themselves, and archives made before that behaviour landed. Restoring one of those does not bring the database back: the task log records that the archive carries no database dump, and the restore stops at the database step rather than completing. In practice this doesn't affect your safety net: the system keeps separate nightly backups of every site regardless.
If you specifically want a fresh backup you can Restore from, you almost never need to touch anything account-wide. When you run the Backup task on a site, the form offers a Backup Mode with three choices:
- Classic single file mysqldump only — just the database, in the classic single file.
- Site files without any DB — your files, no database.
- Site files with classic mysqldump DB — files and a classic single-file database.
Restore brings back exactly what an archive contains: a database-only archive restores the database, a files-only archive restores the files, and partial archives are labelled as such in the backup lists. Only the last mode, Site files with classic mysqldump DB, restores files and database together — and the form already opens on it, so the simplest way to get a fully restore-ready backup is: run Backup and keep the default. Whichever mode you choose bypasses the fast method for just that one backup, without changing anything else.
If instead you'd rather your account always produce classic, restore-ready backups — say you take a lot of manual backups and don't want to remember the mode each time — you can switch the fast method off for the whole account by creating:
~/static/control/MyClassic.info
With that file present, backups go back to including the single-file database dump the Restore task expects — at the cost of slower clone, migrate and backup times on large databases. Remove the file to return to the fast default:
rm ~/static/control/MyClassic.info
If none of this sounds like something you need, it isn't — leave both alone, pick the right Backup Mode on the rare occasion you need a restore, and everything just works.
Related
- Cloning and moving a site — what Clone and Migrate each do, and the safe one-thing-at-a-time path these switches accelerate.
- Everyday site tasks — the Backup and Restore tasks, and the Backup Mode options referred to above.
- Backing up and restoring — how your site's nightly and on-demand backups work, and when a MyQuick archive can and can't be restored.
- Control-file reference — the exact names
and locations of
FastTrack.info,ClassicTrack.infoandMyClassic.info.