• Article for your preferred language does not exist. Below is international version of the article.
Traductions disponibles pour l'article:

How to move from third-party control panels to the Parallels Plesk Panel 11.5

  • Parallels Plesk Panel


This document describes the process of transferring domains from any third party panel to the Plesk, makes overview of general Plesk backup structure and provides simple examples for quick start.


The easiest way to move domains from third-party hosting control panels to the Parallels Plesk Panel is to make domains backup, using native tools of original panel, convert dump created to the format of Plesk Panel and restore this dump on the target machine with installed Plesk.

Full list of migration steps will include:

  1. Making a backup copy of original domains
  2. Converting original backup to the Plesk dump
  3. Packing the dump to ZIP archive in Windows, or tar in Unix
  4. Importing the dump to Plesk Panel (on this stage converted dump is checked for compliance with Plesk backup rules)
  5. Restore imported dump

To prepare dump in Plesk format understanding Plesk basic terms and objects is required, dump must follow backup structure convenience.

Basic term of Plesk business model is “subscription”. Subscription determines customer permissions, limits, hosting type. Subscription has at least one domain, but also can contain add-on domains (with any arbitrary name and settings) and subdomains (which name contain parent domain name). All these domains will be moderated by subscription owner. So on transfer, if several domains belongs to a one person and must have same payment plan, limits and permissions, these domains may be joined to single subscription.

Plesk business model also include such terms as “client” and “reseller”. These objects can have special limits and permissions and manage own subscriptions. Reseller also can have and manage own clients.

Backup Object: Hierarchy and Volumes

Plesk provides opportunities for backing up and restoring nearly all hosting data, which includes its major objects: Administrator account, reseller accounts, client accounts, domain accounts, mail accounts, databases, Web sites, and subdomains. These backup objects are organized into a strict hierarchy where parent object is always an owner of its children. The hierarchy is as follows:

As you can see on the diagram, Plesk backup objects have 4 levels: server, resellers, clients and domains levels. The levels are such that a higher level includes objects on the lower levels but a lower level is completely separated from the higher objects.

User can create either full or partial backup. Full backup is the highest-level backup, it includes all Plesk data: server, admin and all descendant backup objects. Partial backup includes only backup objects you need, of any level. More information about how to create full or partial backup can be found in the article “Defining data for backup".

Restoring a backup, in turn, can also be either full or partial. Full restore revives all data contained in a backup, and partial revives a part. For more restore options see the article “Defining objects for restore section".

As mentioned, each backup object has own data. These data consist of backup object configuration and content:

  • Configuration defines properties of the backup object and its descendants.
  • Content contains binary data related only to the backup object (database backups, mail attachments, etc.).

This means that, for instance, client configuration includes configuration of the domain he/she owns, but their content is completely independent.

This table shows what data (configuration and content) is related to each backup object.

Backup Object Type Own Configuration Own Content
server Settings of server-level services (mail and database servers, SSO, application vault, spam filters and antivirus), server preferences, Sitebuilder configuration, Plesk account templates, license keys, certificates, interface preferences, Plesk billing settings. License keys, custom button icons, Plesk skins, Plesk locales, Web application packages, custom templates of Apache configuration files.
admin Personal Plesk Administrator information.
reseller Personal reseller information, limits and permissions on resources, IP pool and Web application pool configuration, personal domain and client templates settings, custom buttons settings. Virtual host templates, custom button icons.
client Personal client information, limits and permissions on resources, IP pool and site application pool configuration, personal domain and client templates settings, custom buttons settings. Virtual host templates, custom button icons.
domain Resource usage limits, permissions, domain-level service settings (IP address, mail system, mailing lists, DNS, tomcat applications, traffic statistics), custom button and domain alias settings, domain administrator personal information, SSL certificates, hosting type settings. Mailing lists, tomcat applications, custom button icons.
mailuser Personal mail user information, permissions, mailbox settings, mail aliases, forwarding settings, mailgroup settings (only for mailgroup accounts), autoresponders configuration, addressbook (horde turba), SpamAssassin/drweb settings, custom buttons settings. Mail box content, autoresponder attachments, SpamAssassin files, custom button icons.
database Database server settings and database user settings. Database dump.
phosting System user account settings, scripting settings, Web applications settings, Frontpage user credentials, log rotation settings, anonymous FTP settings, additional FTP accounts, list of web-protected site locations, list of domain web users, subdomain settings, web statistics settings, hotlinking protection settings, performance and shared SSL settings. Virtual host content, content of installed Web applications, virtual directories content, web user home directories content.
subdomain System user account information, scripting options, Web applications list, hotlink protection settings, protected directory settings, and shared SSL settings. Content of virtual "sub-host", content of installed Web applications, custom button icons.

Backup Logical Structure

By default, all Plesk backups are created in Plesk backup repository located on Plesk server:

  • in Plesk for Linux/Unix, repository location is specified by the DUMP_D variable defined in the /etc/psa/psa.conf configuration file
  • in Plesk for Windows, repository is located in the %plesk_dir%\Backup folder, where %plesk_dir% is environment variable specifying directory where Plesk is installed (if installed to default locations, it is "C:\Program Files\Parallels\Plesk\")

The repository is structured as follows, starting with the content of repository root folder (we omit auxiliary files and folders which are irrelevant for backing up/restoring Plesk data using pleskbackup/pleskrestore utilities):

  • <info>.xml - Metadata files of full and server-level backups, one per backup, describes configuration and content of server, admin, and all their descendants.
  • <content>.<zip|tar|tgz> - Archives with content of server and admin.
  • [clients] - Directory containing clients owned by admin or having no owner and objects owned by the clients. Organization of the directory is the same as that of "<repository>/resellers/<reseller_id>/clients/".
  • [domains] - Directory containing domains owned by admin or having no owner and objects owned by the domains. Organization of the directory is the same as that of "<repository>/resellers/<reseller_id>/clients/<client_id>/domains/".
  • [resellers] - Directory containing resellers and objects owned by the resellers.
    • [<reseller_id>] - Directories containing backup data of particular resellers, one reseller per directory, and the objects owned by them. The "<reseller_id>" stands for the reseller login name.
      • <info>.xml - Metadata files of the reseller backups, one file per backup, describe configuration and content of the reseller and the objects she owns.
      • <content>.<zip|tar|tgz> - Archives with the reseller content.
      • [domains] - Directory containing domains owned by the reseller and objects owned by the domains. Organization of the directory is the same as that of "<repository>/resellers/<reseller_id>/clients/<client_id>/domains/".
      • [clients] - Directory containing clients owned by the reseller and objects owned by the clients.
        • [<client_id>] - Directories containing backup data of particular clients, one client per directory, and the objects owned by them. The "<client_id>" stands for the client login name.
          • <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 domains owned by the client and objects owned by the domains.
            • [<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 repository folders according to the described structure.

If a partial backup is created, its files will be places according to the place the backup objects have in the hierarchy. For example, if backing up domain owned by reseller JaneDoe, its files will be located in the "<repository>/resellers/JaneDoe/domains/" folder. If backing up reseller JohnDoe who owns a domain and has one client DukeNukem who owns domain, the backup files will be located in the following folders:

  1. <repository root directory>/resellers/JohnDoe/
  2. <repository root directory>/resellers/JohnDoe/domains/
  3. <repository root directory>/resellers/JohnDoe/clients/DukeNukem/
  4. <repository root directory>/resellers/JohnDoe/clients/DukeNukem/domains/

To distinguish files belonging to different backups of the same object, specific prefix and suffix are added to the file names:

  • prefix backup is added by default, and, if you like, you can change it to your own on a per-backup basis
  • suffix designating the backup creation date is always added to each backup file, the date format is <yymmddhhmm>. For example, files of backup created on March 8, 2009, 1:30 am will have suffix 0903080130.

Plesk is capable of exporting backup as a single file (.tgz in Linux/Unix and .zip in Windows). Each archive has the same structure as the repository, the only difference is that there is only one <info>.xml file on each level.

In case 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 single client (called, say, SandyLee) backup is exported, the resulting file will have the following structure:

zip {
    <sandy lee info>.xml

Structure of meta-files (*_info_*.xml)

Info-files must meet the rules described in schema documents (XSD). Plesk validate each backup before restoration and on dump importing. Dumps which have at least one part, which does not meet dump schema cannot be restored or imported to Plesk.

Full dump schema described in plesk.xsd and pmm-common.xsd.

Info-file must be encoded in UTF-8, some attributes and node values use base64 encoding for special symbols escaping, others use CDATA blocks. If some data can contain XML special characters and Backup Manager expects these data in plain, CDATA block must be used.

Info-files contain the following information:

  • Dump version - used on import and pre-deploy stage to convert old-made dumps to current format
  • Agent name - to know which conversion rules to apply
  • Dump info - to show description in the UI
  • Metadata of hosting objects, provisioned by the Plesk, such as domains, mailboxes, server settings, etc.

Full dump XML can contain server, reseller, client and domain, but any of them can be omitted, so there are can be created a dump of server settings only, or only one particular domain, or even client account settings, without his domains. The structure of these objects metadata is stricter, some of them cannot exist without related objects. The order of description nodes in XML is important too - XML with valid relations, but wrong node sequence will be considered as invalid, while checking by XSD schema.

Content of .discovered folder

Each server, reseller, client or domain dump has service folder named ‘.discovered’, which keep meta information of the dump itself. Information from .discovered folder used to get list of dumps available on the corresponding level for particular user. Here we get cached dump part size (including nested dumps size), detect dump relations (belongs to…, contains also…), type (full or partial, server, client or domain) and status (can be used for restoration or not, or can be restored with some issues).

Backup with damaged .discovered content can not be completely restored.

We plan to automatically create .discovered content, but feature does not complete yet.

Content packing

Info-file can contain links to content archives in the dump. On restoration deployer application will process these archives and extract they content, using the rules described in the info-file.

Links and rules provided by ‘cid’ elements of ‘content’ element (see XSD schema). Content of some hosting object, such as web hosting content, can be packed into several archives or single one. For each archive we must create cid element with information about the archive (file name, relative path in the dump, unpacked size, type of content).

Depending on the cid type dump deployer will use different restoration paths and apply different permissions. All the types listed in XSD. You can pack original hosting content to separate archives and each one will be processed with individual rules.

Some cid elements can be placed to one archive to improve performance. Such trick can be used to pack all the content to the single archive, but restore its different parts, using different rules. Main requirement here is to have one cid to the physical archive file and any number of referred cids of other types to this one. By setting offset attribute for particular referred cid we can set concrete folder in the archive, which will be extracted on restoration. There is another important rule for using referred cids: if some content cid has referrers the only referrer’s content will be restored, but not the whole archive.

If schema with referrers is complex for you and performance is not so important, you are free to do not use referrers, but small separate archives.

In the table below showed paths where each type of domain content will be restored on the Plesk environment, inside hosting root (by default "C:\inetpub\vhosts").

Content type Path to restore
docroot <domain-name>/. www-root-folder is “httpdocs” by default, but can be overwritten in domain settings
docroot_ssl <domain-name>/httpsdocs
cgi <domain-name>/cgi-bin
vhost <domain-name>
user-data <domain-name>
apache-files <domain-name>
error_docs <domain-name>/error_docs
logs <domain-name>/logs
ftp_pub <domain-name>/anon_ftp/pub
ftp_incoming <domain-name>/anon_ftp/incoming
private <domain-name>/private
statistics <domain-name>/.plesk/statistics/<domain-name>
webstat <domain-name>/.plesk/statistics/<domain-name>/webstat
webstat_ssl <domain-name>/.plesk/statistics/<domain-name>/webstat-ssl
ftp_stat <domain-name>/.plesk/statistics/<domain-name>/ftpstat
anon_ftpstat <domain-name>/.plesk/statistics/<domain-name>/anon_ftpstat

The same table for subdomains goes below.

Content type Path to restore
docroot <domain-name>/. sub-www-root-folder is subdomain name by default, but can be overwritten in domain settings
docroot_ssl <domain-name>/httpsdocs
cgi <domain-name>/cgi-bin
statistics <domain-name>/.plesk/statistics/
webstat <domain-name>/.plesk/statistics//webstat
webstat_ssl <domain-name>/.plesk/statistics//webstat-ssl
ftp_stat <domain-name>/.plesk/statistics//ftpstat
anon_ftpstat <domain-name>/.plesk/statistics//anon_ftpstat

In the simplest scenario whole domain content can be packed to the single archive and described with cid type “vhost” or “user-data”. Such content will be extracted as is with user permissions to the domain hosting root.

Dump limitations

Because of dump hierarchy uses real domain names as file and folder names you can exceed max path length. To resolve such a problem you must trim long file and folder name and add underscore plus unique digit. New name summary length must be 47 characters long. Example:

original file name:
modified file name:    myveryverylooooooooooooooooooooongdomainname._1

The same rule used for customers and resellers, but length of corresponding files and folders limited by 25 characters.

Dump agent sample

Backup agent in Plesk for Windows presents in binary form, but agent in Plesk for Unix written on Perl programming language and is available in plain. As soon, as Perl agent can be got in sources and in its principles work similar, as agent for Windows, it can show all dump aspects in general and in details. To find out Unix agent sources on the machine with installed Plesk for Unix go to /usr/local/psa/PMM/agents, where located modules of dump creation (general is, and find /usr/local/psa/admin/bin/plesk_agent_manager, which is a main executable file to process command line and run dump operation.

Windows sources also can be got by using special disassembly tools, e.g. Resharper.

Dump restoration

Before dump restoration do not forget perform the following configurations of the Plesk Panel:

  • Register Plesk instance with some license key
  • Assign IP addresses and they types (shared/exclusive) to the target machine
  • Register remote DB server, if you plan to use any

To restore backup there are two possible ways can be used:

  1. Using Panel GUI import dump and restore it, following restore wizard. Cannot be automated. For a big count of domains pack them to the single dump to minimize intermediate operations, such as importing.
  2. Using command line utility “pleskrestore”. Suitable for automated deploy. No pre-deploy actions required.

To find more information about pleskrestore utility visit the following page:

Sample deploy command:

cd ""%plesk_dir%\bin"
pleskrestore.exe --restore C:\ -level domains -verbose -debug -ignore-sign

Sample dump

In the attachment to this document there is archive file with simple, but valid dump, containing content and basic configuration of web hosting of one domain with subdomain. This dump created based on real backup of Plesk instance with one domain. This original backup also attached to this document ( You can observe both, but we will use ahead simple truncated version to understand basics.

For simplicity we do not consider configuration of mail, ftp, databases or other aspects, except web-hosting, its basic parameters, content and DNS configuration. All other aspects will be configured with Plesk default settings.

Dump archive contains the following files:


As can be seen from the listing above general service files and folders have same prefix (bkp) and suffix (timestamp 1309271259) in the name. It is important, because these marks used to distinguish between certain backups and track relations.

File “bkp_info_1309271259.xml” is a general entry point for content deployer. This file contains links to the child dumps (domain dumps, in this sample there are only one domain). In reality this file also can contain server settings, admin account configuration, certificates, Plesk license description.

In the “.discovered” folder described current dump level characteristics, such as dump type, relations, owner and status. Normally status always will be OK.

Currently Plesk does not support restoration of domain dump, if subscription with the same name does not already exist. So we need always create server dump XML, even containing only links to child dumps, therefore you can use root XML file and .discovered content from this sample dump as base and simply add new domain-info nodes to the root XML file to create links to child domain dumps.

Domain dumps located in the “domains” folder, each domain dump in the separate folder named by the name of domain in ASCII (use IDN rules to represent national symbols in ASCII).

File “bkp_example.com_info_1309271259.xml” contains the description of the domain “”, including its hosting settings, DNS records, system user credentials.

While migrating to the Plesk it is possible to keep original IPs for domains. IP-mapping file must be provided on restore in such case. But to skip this step better replace these IPs to the target IPs on the dump preparation stage. So fill out “ip” node content in domain XML on backup converting to the Plesk format. IP of type “exclusive” can be assigned to only one domain. You can assign for domain IP v4 or v6 or both.

Node “webspace-status” manages the state of web hosting (enabled/disabled).

Node “status” controls the state of whole subscription.

Node “phosting” defines physical hosting settings, including system user account, content description, available scripting on domain, IP for web-hosting.

Notice the element content with child element cid. It is a link to the domain webspace content archived (corresponding archive resides in the same folder). If this content node will omit - no content will be restored for domain, but the configuration only.

Node “sites” can contain zero or more subdomains.

More information about XML node meanings can be found in the comments of dump schema files (plesk.xsd and pmm-common.xsd).

Database dump

On Windows Plesk able to deploy MSSQL and MySQL databases.

Plesk uses native mysqldump utility to backup/restore MySQL databases, so MySQL dump of a database managed by third-party hosting panel must be made in mysqldump format.

For MSSQL databases Plesk support two dump types: SQL-script and native MSSQL dump format. Native dump format requires to have local MSSQL instance on the target machine. So for transferring of MSSQL databases the following solutions can be used:

  • Move local or remote database content using SQL-script dump format.
  • Move database content in native MSSQL dump format to MSSQL instance, installed on the same machine, where Plesk is installed.
  • Do not move database content, but keep it on the source machine, transfer DB connection settings only to register these databases as remote databases on the target Plesk instance. It is the fastest solution for transferring, but requires to keep source databases as is and make native dump usage impossible in future backup operations on target machine. Same solution with transferring DB config without content can be applied to MySQL databases too.

Especially for transfer from third-party environment the most convenient way is to transfer connection settings only, but if you want to have MSSQL backup in native format in the future consider to use SQL-script backup. Using of MSSQL native dump for transfer in general is not an option, because requires local MSSQL instance.

Database transferring must meet the following requirements:

  1. Each database server type, present on the source, must be configured on target machine before transferring
  2. While configuring database servers on the target machine you must provide credentials of admin user for each database server. This user must be able to create databases and other users. For the case of remote DB server admin user must be granted to access remotely at least from target Plesk machine, where you plan to restore the content.

With this document there are two samples provided:

  1. - dump of real Plesk domain with databases
  2. - trimmed version of real dump to illustrate simple case of database content deployment

Lets consider content.

In the "domains/" there are description of domain with subdomain and 3 databases: local MySQL database, local MSSQL database and remote MySQL database.

To be able to restore remote databases without content transferring (just register in the Plesk) you must set environment variable ""PLESK_MIGRATION_MODE = 1" in the same shell session, where pleskrestore utility will be executed, overwise DB content will be missing. In the example database “remote_db” have no inner content block and uses external IP, so it will be processed as remote database on restore. With PLESK_MIGRATION_MODE environment variable set to 1 database will be attached to the Plesk environment without content moving. In other hand, if you add content block to this database and do not set PLESK_MIGRATION_MODE variable it will be processed the same way, as local database (content from archive will be deployed on target server - on the remote DB server in this case).

Each database in example has one user. Additionally there are another one user in the “dbusers” block, named “any_local_mysql”, which is granted to access all local MySQL databases created under current domain.


49af2da0f2dd4c81e962790bbbd0c2b4 56797cefb1efc9130f7c48a7d1db0f0c

Cet article vous-a-t-il aidé ?
Indiquez ce que nous pouvons améliorer.
Oui Non
Virtualisation de desktops
- Parallels Desktop 9 pour Mac
- Pour les entreprises
- Parallels Desktop pour Mac Enterprise Edition
- Parallels Management-Mac pour Microsoft SCCM
- Tous les Produits de virtualisation de desktops >>
Plates-formes d'automatisation cloud et d'hébergement
Parallels Plesk Panel Suite
- Parallels Plesk Panel
- Parallels Plesk Automation
- Parallels Web Presence Builder
Parallels Automation Suite
- Parallels Automation
- Parallels Automation for Cloud Infrastructure
- Parallels Business Automation Standard
Parallels Virtualization Suite
- Parallels Cloud Server
- Parallels Virtuozzo Containers
- Parallels Virtual Automation
Services & Ressources
- Services Cloud Acceleration
- Services professionnels
- Services d'assistance
- Formation & Certification