SCM Backup is configured in YAML, by editing the config file
SCM Backup automatically makes a backup of its own configuration.
On each run, the following files are copied to the backup folder, into a subfolder named
The logger’s config file
The folder (on the machine where SCM Backup runs) where all the backups will be stored.
The folder must already exist, SCM Backup won’t create it.
When an error occurs, SCM Backup will wait that many seconds before exiting the application.
SCM Backup uses the source control software already installed on your system. By default, it assumes that the required SCMs are installed in your path.
If this isn’t the case, or if you have multiple versions of the same SCM on your system and want SCM Backup to use a specific one, you can specify the complete path to the executable in the config file.
scms: - name: git path: 'c:\git\git.exe'
Settings for sending log information via email.
By default, the whole section is commented out via
#. To enable it, remove the comments so it looks like this:
email: from: firstname.lastname@example.org to: email@example.com server: smtp.example.com port: 0 useSsl: false userName: testuser password: not-the-real-password
Fill all settings with the proper values for your server.
SCM Backup will try sending emails when an un-commented
SCM Backup is able to backup from multiple source code hosters, and multiple accounts per hoster.
For example, your GitHub user may be a member of an organization, and you may want to backup all repositories of your user, and all repositories of that organization.
In SCM Backup terms, these would be two different sources: your GitHub user would be one source, and the organization would be a second one.
You can define as many sources as you want in the config file, in this format:
sources: - title: some_title hoster: github type: user name: your_user_name - title: another_title hoster: github type: org name: your_org_name
Each source must have at least those four properties:
Must be unique in the whole config file.
For each source, SCM Backup will create a sub-folder named like the source’s title in the main backup folder.
The source code hoster from which you want to backup. See the sub-pages for valid values for each hoster.
org, depending if you want to backup an user or a organization.
The name of the user/organization you want to backup.
With these settings, SCM Backup will backup public repositories only. For private repositories, additional properties must be set ⇒ see Authentication
See the respective sub-page for detailed documentation per hoster:
Optional: For each source, you can specify a list of repositories you do not want to be backed up.
sources: - title: some_title hoster: github type: user name: your_user_name ignoreRepos: - repo1 - Some-Other-Repo
The repository names are case-sensitive!
For hosters where the repositories are “sub-items” of the users (like GitHub), you just need to specify the repository name, not the user name (i.e.
Optional. The opposite of
ignoreRepos (see above): if a list of repos is specified in
includeRepos, only these repos will be backed up, the rest will be ignored.
sources: - title: some_title hoster: github type: user name: your_user_name includeRepos: - repo1 - Some-Other-Repo
When the same repo is specified in both
includeRepos, ignoring “wins” and the repo will not be backed up.
Without authentication, SCM Backup can only backup your public repositories.
In this case, it shows a warning:
To backup your private repositories as well, you need to authenticate by setting two more properties for the source:
Name of the user which is used for authentication.
The password/token/whatever (this varies wildly depending on the source code hoster)
If your password contains at least one of the special characters listed here, you should enclose it in quotes.
password: 'foo?' instead of
If you don’t want to save your passwords directly in a config file, SCM Backup is able to get them from environment variables.
If an environment variable named
some_variable exists, the string
%some_variable% will be replaced by the value of that variable.
This works for parts of the password as well:
If you use environment variables, you must quote the string as shown in the examples above.
password: %some_variable% will not work because in YAML, strings containing
% must always be quoted.
Additional configuration options, available in this form:
options: CATEGORY: KEY : VALUE
options: backup: removeDeletedRepos : false
SCM Backup will detect repositories which exist in the local backup, but not at the hoster…so at some point, they were deleted from the hoster.
removeDeletedRepos is set to true, SCM Backup will delete those repositories from the local backup folder.
options: backup: logRepoFinished: false
While SCM Backup is running, it outputs a log message for each repo that is backed up:
Backing up source: some_source Git: https://github.com/some_user/some_repo.git Git: https://github.com/some_user/another_repo.git ...
These messages are generated before SCM Backup tries to backup the repo, but that’s not obvious for the user just by looking at the messages.
To make it more clear when the backup of each repo starts and finishes (e.g. when an error happens, to be 100% sure which repo caused it), you can set
logRepoFinished to true, which outputs a second log message for each repo when its backup is finished:
Backing up source: some_source Git: https://github.com/some_user/some_repo.git Finished Git: https://github.com/some_user/another_repo.git Finished ...