mirror of
https://we.phorge.it/source/phorge.git
synced 2024-11-23 15:22:41 +01:00
117519f396
Summary: Not sure this would have avoided the issue, but I remember a couple of other people asking about migrations, so try to make it more clear/obvious that the backup tools are also useful for migrations. Although this is reasonably obvious when you think about it, it's not very obvious when you're trying to do a migration, and maybe making it more explicit will help. Test Plan: Read new documentation. Reviewers: chad, btrahan Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D7992
103 lines
3.8 KiB
Text
103 lines
3.8 KiB
Text
@title Configuring Backups and Performing Migrations
|
|
@group config
|
|
|
|
Advice for backing up Phabricator, or migrating from one machine to another.
|
|
|
|
= Overview =
|
|
|
|
Phabricator does not currently have a comprehensive backup system, but creating
|
|
backups is not particularly difficult and Phabricator does have a few basic
|
|
tools which can help you set up a reasonable process. In particular, the things
|
|
which needs to be backed up are:
|
|
|
|
- the MySQL databases;
|
|
- uploaded files; and
|
|
- your Phabricator configuration files.
|
|
|
|
This document discusses approaches for backing up this data.
|
|
|
|
If you are migrating from one machine to another, you can generally follow the
|
|
same steps you would if you were creating a backup and then restoring it, you
|
|
will just backup the old machine and then restore the data onto the new
|
|
machine.
|
|
|
|
= Backup: MySQL Databases =
|
|
|
|
Most of Phabricator's data is stored in MySQL, and it's the most important thing
|
|
to back up. You can run `bin/storage dump` to get a dump of all the MySQL
|
|
databases. This is a convenience script which just runs a normal `mysqldump`,
|
|
but will only dump databases Phabricator owns.
|
|
|
|
Since most of this data is compressible, it may be helpful to run it through
|
|
gzip prior to storage. For example:
|
|
|
|
phabricator/ $ ./bin/storage dump | gzip > backup.sql.gz
|
|
|
|
Then store the backup somewhere safe, like in a box buried under an old tree
|
|
stump. No one will ever think to look for it there.
|
|
|
|
= Restore: MySQL =
|
|
|
|
To restore a MySQL dump, just pipe it to `mysql` on a clean host. (You may need
|
|
to uncompress it first, if you compressed it prior to storage.)
|
|
|
|
$ gunzip -c backup.sql.gz | mysql
|
|
|
|
= Backup: Uploaded Files =
|
|
|
|
Uploaded files may be stored in several different locations. The backup
|
|
procedure depends on where files are stored:
|
|
|
|
**Default / MySQL**: Under the default configuration, uploaded files are stored
|
|
in MySQL, so the MySQL backup will include all files. In this case, you don't
|
|
need to do any additional work.
|
|
|
|
**Amazon S3**: If you use Amazon S3, redundancy and backups are built in to the
|
|
service. This is probably sufficient for most installs. If you trust Amazon with
|
|
your data //except not really//, you can backup your S3 bucket outside of
|
|
Phabricator.
|
|
|
|
**Local Disk**: If you use the local disk storage engine, you'll need to back up
|
|
files manually. You can do this by creating a copy of the root directory where
|
|
you told Phabricator to put files (the `storage.local-disk.path` configuration
|
|
setting).
|
|
|
|
For more information about configuring how files are stored, see
|
|
@{article:Configuring File Storage}.
|
|
|
|
= Restore: Uploaded Files =
|
|
|
|
To restore a backup of local disk storage, just copy the backup into place.
|
|
|
|
= Backup: Configuration Files =
|
|
|
|
You should also backup your configuration files, and any scripts you use to
|
|
deploy or administrate Phabricator (like a customized upgrade script). The best
|
|
way to do this is to check them into a private repository somewhere and just use
|
|
whatever backup process you already have in place for repositories. Just copying
|
|
them somewhere will work fine too, of course.
|
|
|
|
= Restore: Configuration Files =
|
|
|
|
To restore configuration files, just copy them into the right locations.
|
|
|
|
= Security =
|
|
|
|
MySQL dumps have no builtin encryption and most data in Phabricator is stored in
|
|
a raw, accessible form, so giving a user access to backups is a lot like giving
|
|
them shell access to the machine Phabricator runs on. In particular, a user who
|
|
has the backups can:
|
|
|
|
- read data that policies do not permit them to see;
|
|
- read email addresses and object secret keys; and
|
|
- read other users' session and conduit tokens and impersonate them.
|
|
|
|
Some of this information is durable, so disclosure of even a very old backup may
|
|
present a risk. If you restrict access to the Phabricator host or database, you
|
|
should also restrict access to the backups.
|
|
|
|
= Next Steps =
|
|
|
|
Continue by:
|
|
|
|
- returning to the @{article:Configuration Guide}.
|