Backup File Structure
By default, all backups are created in a backup storage located on the
Plesk-managed server: in a storage specified by the DUMP_D
variable
defined in the /etc/psa/psa.conf
configuration file
The storage is structured as follows, starting with the content of the
storage root folder (we omit additional files and folders which are
irrelevant for backing up and restoring Plesk data using pleskbackup
and pleskrestore
utilities).
< info >.xml
|
Metadata files of full and server-level backups, one per backup, describe configuration and content of server, admin, and all their descendants. | ||
---|---|---|---|
< content >.<zip|tar|tgz>
|
Archives with content of server and admin. | ||
clients/ |
Directory containing the following backup data:
Organization of the directory is the same as that of
|
||
domains/ |
Directory containing the following backup data:
Organization of the directory is the same as that of
|
||
resellers/ |
Directory containing the following backup data:
|
||
< reseller ID >/
|
Directories containing backup data of particular resellers, one reseller per directory, and the objects owned by them. The |
||
< info >.xml
|
Metadata files of the reseller backups, one file per backup, describe configuration and content of the reseller and the objects they own. | ||
< content >.<zip|tar|tgz>
|
Archives with the reseller content. | ||
domains/ |
Directory containing the following backup data:
Organization of the directory is the same as that of
|
||
clients/ |
Directory containing the following backup data:
|
||
<client ID> /
|
Directories containing backup data of particular clients, one client per directory, and the objects owned by them. The |
||
< info >.xml
|
Metadata files of the client backups, one file per backup, describe configuration and content of the client and the objects he owns. | ||
< content >.<zip|tar|tgz>
|
Archives with the client content. | ||
domains/ |
Directory containing the following backup data:
|
||
<international domain name> <domain ID> /
|
Directories containing backup data of particular domains, one domain per directory, and the objects owned by them. The domain ID is omitted if the domain IDN is less than 47 symbols. |
||
< info >.xml
|
Metadata files of the domain backups, one file per backup, describe configuration and content of the domain and the objects it owns. | ||
<content> | Other files and folders which contain domain contents, and its children contents and configurations. |
Files of each backup are placed in the storage folders according to the described structure.
f a partial backup is created, its files will be placed according to the
location of the backup objects in the hierarchy. For example, if backing
up domain example.com owned by reseller JaneDoe, its files will be
located in the
<storage root directory>
/resellers/JaneDoe/domains/example.com/
folder. If backing up reseller, JohnDoe, who owns a domain joe.info and
has one client, DukeNukem, who owns domain sample.org, the backup files
will be located in the following folders:
-
<storage root directory>
/resellers/JohnDoe/
-
<storage root directory>
/resellers/JohnDoe/domains/joe.info/
-
<storage root directory>
/resellers/JohnDoe/clients/DukeNukem/
-
<storage root directory>
/resellers/JohnDoe/clients/DukeNukem/domains/sample.org/
To distinguish files belonging to different backups of the same object, a specific prefix and suffix are added to the file names:
- the
backup
is added by default, and, if you like, you can change it to your own on a per-backup basis - a suffix designating the backup creation date is always added to each
backup file, and the date format is
<yymmddhhmm>
. For example, the files of a backup created on 6 April 2011, 8:58 PM will have the suffix1104062058
.
Plesk is capable of exporting a backup as a single .tgz
file. Each
archive has the same structure as the storage, the only difference is
that there is only one <info>
.xml
file on each level.
If a partial backup is exported, the resulting file structure is reduced from the top so that the highest level corresponds to the level of the highest backup object. For example, if a backup of a single customer (called, for example, SandyLee) is exported, the resulting file will have the following structure:
zip {
-
<sandy lee info>
.xml
-
<content>
.zip
-
domains/
-
subscription1/
...
-
subscription_N/
-
...
}
-