Child pages
  • Operation and Hosting Packages - Backup Concept
Skip to end of metadata
Go to start of metadata

Which data is backed up and in what format?

User data

By user data we mean the actual application data. In a typical Atlassian application, for example, this includes the following:

  • Database (PostgreSQL or MySQL)
  • Page attachments in Confluence
  • Issue attachements in Jira
  • Repositories in Bitbucket

We employ a "two-stage" backup concept. Firstly, we back up the customer's system directly:

  • Customer systems use ZFS as the file system. Hourly snapshots of the application data and the database are generated at the block level.
  • By default, these snapshots are stored for the following periods:
    • 24 hour snapshots
    • 7 day snapshots
    • 2 week snapshots
    • 1 month snapshots
  • Local snapshots of this kind do not help in the event of a total system failure, but protect against short-term corruption of the data, which could occur as a result of human error.

Secondly, user data is backed up to a backup server at another location (Hetzner in Germany):

  • Daily backup.
  • The data is copied from the customer's system to the backup server using rsync.
  • The application data and the database are backed up (binary format, no dump).
  • The data source is a local ZFS snapshot of the customer's system so that a consistent backup is created (database and complete user data always have matching time stamps). To create this snapshot, the database is temporarily shut down.
  • By default, these backups are kept for the following periods:
    • 7 day backups
    • 4 week backups
    • 3 month backups
  • If the system fails completely, these backups can be restored.
  • Being hosted in separate locations (customer systems and backup systems do not run in the same data center) further reduces risks (e.g. in the event of natural disasters), while still complying with European data protection directives.

Configuration of the customers's systems

The configuration data for the customer's systems - e.g. web server settings - are not captured by classic backups. Instead, these are covered within the global configuration management system provided by //SEIBERT/MEDIA. This data is therefore stored in a Git repository, which is stored in our own Bitbucket instance. Sensitive data is encrypted and only accessible to a limited number of people. Bitbucket itself is subject to the same security mechanisms as those described above.

Backup server

Encryption

  • All data is transferred from the customer's system to the backup server in encrypted form (SSH) and stored securely on the backup server.
  • Encryption is performed using LUKS on the backup server.
  • The encryption key is never stored on the backup server, but is entered manually by the administrators after a reboot.

Redundancy

  • The backup servers usually have three hard disks.
  • ZFS is used as a file system with RAIDZ (comparable to RAID5). If a hard disk fails, it can be exchanged without data loss.

Data privacy between customers

  • The various customers' backup spaces are separated at the file system level.
  • Backup clients also have strictly regulated access rights to prevent unauthorized access to backups.

Round-robin backups to two or more different backup servers

Our backup system supports multiple backup servers as targets. This mode is used by default. Today's backup is stored on server $A, tomorrow's backup is stored on server $B, then it continues on server $A. This spread further increases reliability.

Custom configurations

Customizations

Both the local ZFS snapshots and the regular backups are configurable with regard to the retention periods.

  • No labels