Icon

You are viewing the documentation of TeamCity 10.x and 2017.x, which is not the most recently released version of TeamCity.
View this page in TeamCity 2018.1 documentation or refer to the listing to choose the documentation corresponding to your TeamCity version.

 
Skip to end of metadata
Go to start of metadata

On this page:

Server Manual Backup

Other ways to create a backup are available. You can use the instructions on this page if you want fine-grained control over the backup process or need to use a specific procedure for your TeamCity backups. Manual backups can also be the most performant way to create and restore backups as they can be tailored to the specific infrastructure in use.

Icon

Before performing the backup procedures, it is recommended to stop the TeamCity server. This way you ensure the backup taken is consistent. If you create a backup while the TeamCity server is running, currently updated data (mostly related to queued and running builds as well as settings updates) can appear in inconsistent state after restore. When performing backup while the server is running first create the database backup and then that of the files in the TeamCity Data Directory.

The following data needs to be backed up:

TeamCity Data Directory

TeamCity Data Directory stores:

  • server settings, projects and build configurations with their settings (i.e. all that is configured via the Administration web UI)
  • build artifacts by default, unless a different location is configured. Build logs are also stored as a part of the build artifacts
  • current operation files, internal data structure, etc.

For more details on the directory structure and data, refer to the TeamCity Data Directory section.

If necessary, you can exclude parts of the directory from the backup to save space — you will lose only the excluded data. You may safely exclude the "system/caches" directory from the backup — the necessary data will be rebuilt from scratch on TeamCity startup.


If you decide to skip the backup of data under <TeamCity Data Directory>/system directory, make sure you note the most recent files in each of the artifacts, messages and changes subdirectories and save this information. It will be needed if you decide to restore the database backup with the TeamCity Data Directory corresponding to a newer state than that of the database.
The <TeamCity Data Directory>/system/buildserver.* files store the internal database (HSQLDB) data. You need to back them up if you use HSQLDB (the default setting not suitable for production use).

Database Data

The database stores all information on the build results (build history and all the build-associated data except for artifacts and build logs), VCS changes, agents, build queue, user accounts and user permissions, etc.

  • If you use the HSQLDB, the internal database (default setting, not recommended for production), the database is stored in the files residing directly in the <TeamCity Data Directory>/system folder. All files from the directory can be backed up. You may also refer to the HSQLDB backup notes.
  • If you use an external database, back up your database schema used by TeamCity with database-specific tools.
    For the external database connection settings used by TeamCity, refer to the <TeamCity Data Directory>/config/database.properties file. You can also see the corresponding installation section.

Application Files

You do not need to back up TeamCity application directory (web server alone with the web application), provided you still have the original distribution package and you did not:

  • place any custom libraries for TeamCity to use
  • install any non-default TeamCity plugins directly into web application files
  • make any startup script/configuration changes.

If you feel you need to back up the application files:

  • If you use a non-war distribution: back up everything under <TeamCity home directory> except for the temp and work directories.
  • If you use the war distribution, follow the backup procedure of the servlet container used.

Log files

If you need TeamCity server log files (which are mainly used for problem solving or debug purposes), back up the <TeamCity Home>/logs directory.

Icon

You may also want to back up TeamCity Windows Service settings, if they were modified.

Manual Restoration of Server Backup

If you need to restore backup created with the web UI or maintainDB utility, please refer to Restoring TeamCity Data from Backup. This section describes restoration of a manually created backup.

You should always restore both the data in the <TeamCity Data Directory> and data in the database. Both the database and the directory should be backed up/restored in sync.

TeamCity Data Directory Restoration

You can simply put the previously backed up files back to their original places. However, it is important that no extra files are present when restoring the backup.
The simplest way to achieve this is to restore the backup over a clean installation of TeamCity. If this is not possible, make sure the files created after the backup was done are cleared. Especially the newly created files under the artifacts, messages, changes directories under <TeamCity Data Directory>/system.

TeamCity Database Restoration

The database must be restored using the database-specific tools and methods. You might also want to use database-specific methods to make the restore faster (like setting SQL Server "Recovery Model" to "Simple").

Prior to restoring, make sure there are no extra tables in the schema used by TeamCity.

Restoration to New Server

If you want to run a copy of the server, make sure the servers use distinct data directories and databases. For an external database, make sure you modify settings in the <TeamCity Data Directory>/config/database.properties file to point to a different database.

Restoring Build Logs

Build logs located in the /logs subdirectory of /artifacts from multiple artifact directories are backed up and restored into the single directory system/<project ID>/<build configuration name>/<internal_build_id>/.teamcity/logs.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • No labels