### dest

Destination Help

Backup to Directory

If this option is used, TwcBackup will store all backups in a (local) directory.

Directory

Absolute path to the directory (example: /BACKUP).

Backup to External Disk

If this option is used, TwcBackup will mount an external disk for backup, store the backups on that external disk, and umount that disk on each backup run.

Disk Label

The external disk must have a filesystem label that corresponds to this property, otherwise the backup will fail.

Backup Weekday Configuration

Backup Time

The backup of the work of the day usually occurs after the day is over. Since TwcBackup needs to figure out which weekday this backup belongs to, the user needs to specify whether the backup is started on the same day, in the evening or on the next day, in the morning.

The first case "same day" will not require extra steps in the backup, but if "next day" is selected, TwcBackup will subtract one day to make the data generated on friday also match the "friday" label in the TwcBackup configuration of the external disk. ### media

Media Help

If the destination of the backup is an external disk (and not a local directory), each disk needs to added to the TwcBackup configuration.

External Disk Name

This is a name the external disk has so that end users can identify it.

External Disk UUID

This should be the UUID of the external disk (as printed out by blkid). If backup is started and the UUID of the attached disk is not found among all disks registered in the configuration, the backup will fail.

Days of the Week

TwcBackup will compare the day of the week of the backup to the days of the week the backup media is allowed to store. If this doesn't match, the backup will fail. Through this setting, it is possible to ensure that one hard disk is used for fridays backup, and another hard disk for all other days. ### tar

Tar Backup Help

Tar Backup is a full/incremental backup strategy that creates tar files of the files that are included in the backup. On first run, a full backup is created. Then only the differences to that full backup are stored each time a backup is created. After a while, a new full backup is created.

Tar Backups usually require more diskspace than bfsync backups, so: if you can, use bfsync backups instead.

Name

The Name property should contain a unique name for this Tar Backup step.

It may contain letters, numbers and underscores.

Include Dirs

This is a list of directories that should be included in the Backup.

Exclude Dirs (optional)

This is a list of directories that should not be included in the Backup. Exclude Dirs should be relative to Include Dirs.

Example: to backup /home but not /home/stefan, Include Dirs should be set to /home, and exclude dirs should be set to stefan. (XXX).

Full Backup every N Days

The number of days between the full backups. ### rsync

RSync Help

RSync Backups will just rsync directories to the backup device. It can neither be used to access old backups, nor will it delete files that have been deleted on the source directory. Thus: if you can, use bfsync backups instead.

Name

The Name property should contain a unique name for this RSync Backup step.

It may contain letters, numbers and underscores.

Include Dirs

This is a list of directories that should be included in the Backup.

Exclude Dirs (optional)

This is a list of directories that should not be included in the Backup. Exclude Dirs should absolute paths (like Include Dirs).

Example: to backup /home but not /home/stefan, Include Dirs should be set to /home, and Exclude Dirs should be set to /home/stefan.

Ignore existing Files (optional)

If this option is set, files that already exist on the backup will not be updated, even if they were modified in the source directory. It is implemented using the rsync --ignore-existing option. ### pg_dump

Postgres Dump Help

Name

The Name property should contain a unique name for this Postgres Backup step.

It may contain letters, numbers and underscores.

Include DBs

A list of databases that should be included in the backup, in DBNAME:PORT format (i.e. mydb:3456).

To backup all databases on the machine, the value can be set to *.

Exclude Dirs

Usually this should be set to "data".

TWC installations usually store the postgres data in a subdirectory data (relative to the directory in which documents/files/scripts/... are stored). This subdirectory doesn't need to be included in the backup, since a dump of the postgres database is made. ### pre_script

Pre-Script Help

Pre-Scripts are shell commands that are run before every backup. If one pre-script fails, the backup is not performed.

A typical task for pre-scripts is shutting down a database server before the backup is done.

Run

One or more commandlines to be run before backup. These will be executed with the user that runs the backup script (typically root). ### post_script

Post-Script Help

Post-Scripts are shell commands that are run after every backup. Even if the backup fails, or one post-script fails, all post-scripts will always be executed.

A typical task for post-scripts is restarting a database server after the backup is done.

Run

One or more commandlines to be run after backup. These will be executed with the user that runs the backup script (typically root). ### bfsync_common

BFSync Common Help

The options in this section affect all bfsync repositories. If no bfsync repositories are configured, the options will have no effect.

Export File Lists to Postgres

After the backup has finished, twcbackup can export the file lists of the bfsync repositories to a Postgres Database. This feature is optional, if no database name, user, ... is configured, nothing will be exported.

The exported file lists are useful for tools that display the contents of the bfsync repositories (so it is for instance possible to search for all versions of a specific file that are contained in a bfsync repository).

Database Name

The postgres database name of the database that should contain the file lists.

User

The postgres user used when connecting the database.

Password

The postgres password used when connecting the database.

Host

The host the postgres database server is running on.

Port

The tcp port used when connecting the postgres database server. ### bfsync_repo

BFSync Repository Help

When bfsync backups are used, one or more bfsync repository needs to be created. The backups stored inside one bfsync repository will be deduplicated at file level (but only within each repository). Old versions of all files will be kept, so that it is possible to restore old backups. There are no full/incremental backups if bfsync is used, so each backup will appear to be a full backup, but the contents of each file will only be stored once (SHA1-hashes are used for deduplication).

Name

The name of the bfsync repository. Each repository needs to have a different name.

It may contain letters, numbers and underscores.

Database Cache Size (Mb)

The database cache size is the amount of system memory in megabytes that is used as cache for the bfsync repository. If the database cache size is too small, the time required to add files to the repostory will become huge. If the database cache size is too large, the machine that does the backups will slow down or not be able to perform the backup due to lack of RAM.

At least 100 MB cache per 1.000.000 files stored should be used, more is better, if you can afford it.

Since the cache will be in shared memory, the system wide shared memory limits need to be large enough for the cache. See SHARED MEMORY CONFIGURATION in the bfsync manpage for details.

To avoid excessive RAM usage, all bfsync repository caches combined should be considerably less than the amount of system memory.

Deletion of old Backups

Whenever a backup runs, new data will be added to the bfsync repository. To ensure that the repository doesn't grow too large, this configuration describes which backups should be deleted.

First of all, some of the backups are tagged as "daily backup". If the backup is done once a day, every backup will be a daily backup, if the backup runs more than once a day, either the first or last backup of the day can be used as daily backup.

Based on the daily backups, "weekly backups" can be defined by weekday: for instance Daily Backup on Monday/... can be used as weekly backup. The "monthly and yearly backups" are also choosen among the daily backups; here the first or last daily backup of the month/year can be used as monthly or yearly backup.

The actual deletion rule works by defining which backups are to be kept, and all other backups will be deleted.

You can keep the most recent N backups. This is important mainly if the backup runs more than once every day, since then there will be backups which are neither tagged daily nor weekly nor monthly nor yearly.

In addition to keeping the most recent N backups, there is a parameter for each tagged backup: that way, you can keep the most recent N daily backups, the most recent N weekly backups, the most recent N monthly backups and the most recent N yearly backups.

All backups that are not on one of the keep lists are automatically deleted. ### bfsync_backup

BFSync Backup Help

Name

The name of the bfsync backup. Each backup needs to have a different name.

It may contain letters, numbers and underscores.

Repo

The name of the repository to store the backup. The repository must be the name of one of the repositories created (under BFSync Repository).

Source Host (optional)

If this field contains a value, TwcBackup will fetch the data from this host. Ssh ids should be used to allow TwcBackup to access this host as root without password.

Include Dirs

This is a list of directories that should be included in the Backup.

Exclude Dirs (optional)

This is a list of directories that should not be included in the Backup. Exclude Dirs should absolute paths (like Include Dirs).

Example: to backup /home but not /home/stefan, Include Dirs should be set to /home, and Exclude Dirs should be set to /home/stefan.

One Filesystem (optional)

If this option is activated, only those files are backuped that reside on the same filesystem that Include Dirs are on.

Remote Shell

For local backups (Source Host is empty), this option is ignored. For remote backups, it can be used to configure the remote shell that is used to transfer the data. Usually, ssh is a good choice, but since ssh encrypts all traffic, it slows down the backup on very fast local networks.

Rsh on the other hand doesn't slow down the backup, but it should only be used if the network is completely trusted, since neither the transfer nor the authentication are secure. ### bfsync_windows_backup

BFSync Windows Backup Help

Name

The name of the bfsync windows backup. Each backup needs to have a different name.

It may contain letters, numbers and underscores.

Repo

The name of the repository to store the backup. The repository must be the name of one of the repositories created (under BFSync Repository).

SMB Share

Samba share that contains the data to be included in the backup. Usually this will be a name like \\HOST\SHARE .

User

Username to use for connecting to the samba share.

Password

Password to use for connecting to the samba share.

Include Dirs

This is a list of directories that should be included in the backup. This should be in Unix path format, like /foo/bar.

Exclude Dirs (optional)

This is a list of directories that should not be included in the Backup. Exclude Dirs should be relative to Include Dirs.

Example: to backup /foo but not /foo/bar, Include Dirs should be set to /foo, and Exclude Dirs should be set to /foo/bar. ### bfsync_clone

BFSync Replication Help

Replication can be used to clone the contents of a local or remote bfsync repository so that all changes that are done to the source repository are also done to the destination repository.

Name

The name of the bfsync replication. Each replication needs to have a different name.

It may contain letters, numbers and underscores.

Pull History from Master Repo

The name of the master repository that contains the history that should be replicated. This master repository will be cloned with bfsync clone the first time the replication is run, and updated each time with new history entries using bfsync pull.

The repository can be local (then it would be a local path like /home/stefan/files.bfsync) or remote (then it would be something like stefan@space.twc.de:files.bfsync).

Get Files from Repo

Since the master repository contains only the history, but no file contents, this second repository needs to be specified. It must be a clone of the master repository that is replicated, and should contain the file contents of (ideally) all files that the history contains.

Each time the replication is run this repository is used as a source of files (so bfsync get will be used).

The repository can be local (then it would be a local path like /home/stefan/files.bfsync) or remote (then it would be something like stefan@space.twc.de:files.bfsync).

User (optional)

If this setting is omitted, the repository will be replicated as root. If a user is specified, the repository will be replicated as this user (all files will belong to that user).

Database Cache Size (Mb)

The database cache size is the amount of system memory in megabytes that is used as cache for the bfsync repository. If the database cache size is too small, the time required to add files to the repostory will become huge. If the database cache size is too large, the machine that does the replication will slow down or not be able to perform the replication due to lack of RAM.

At least 100 MB cache per 1.000.000 files stored should be used, more is better, if you can afford it.

Since the cache will be in shared memory, the system wide shared memory limits need to be large enough for the cache. See SHARED MEMORY CONFIGURATION in the bfsync manpage for details.

To avoid excessive RAM usage, all bfsync repository caches combined should be considerably less than the amount of system memory.

Remote Shell

This setting can be used to configure the remote shell that is used to transfer the data. Usually, ssh is a good choice, but since ssh encrypts all traffic, it slows down the replication on very fast local networks.

Rsh on the other hand doesn't slow down the replication, but it should only be used if the network is completely trusted, since neither the transfer nor the authentication are secure. ### report

Report Help

After each run, TwcBackup will send a report via email, either with a confirmation that the backup was performed, or with an error message.

Report Title

A title for the backup report. Usually (if you have more than one machine), it should be set to something that can be used to identify the machine.

EMail Address

A list of email addresses the report should be mailed to.