Skip to main content

Single Node Installs: Storage and Backup Guidelines

General storage recommentations for single-node instances

  • /mnt (or a common root for all <component>_data_path variables) should be a distinct mount point
    • Ideally this would have an independent lifecycle from the server itself
    • Ideally this would be easily snapshot-able, either at a filesystem level or with the backing storage

Adminbot storage:

  • Files stored with uid=10006/gid=10006, sample config uses /mnt/data/adminbot for single-node instances
    • The backing path for single node instances can be changed by setting bot_data_path in the adminbot config directory
  • Storage space required is proportional to the number of user devices on the server. 1GB is sufficient for most servers
    • The size of the PVC can be changed by setting bot_data_size in the adminbot config directory

Auditbot storage:

  • Files stored with uid=10006/gid=10006, sample config uses /mnt/data/auditbot for single-node instances
    • The backing path for single node instances can be changed by setting bot_data_path in the auditbot config directory
  • Storage space required is proportional to the number of events tracked. 1GB is sufficient with the sample config logfile_size / logfile_keep values
    • The size of the PVC can be changed by setting bot_data_size in the auditbot config directory

Chatterbox storage:

  • Files stored with uid=10008/gid=10008, sample config uses /mnt/media/chatterbox-bot-data for single-node instances
    • The backing path for single node instances can be changed by setting bot_data_path in the chatterbox config directory
  • Storage space required is proportional to the number of user devices on the server. 1GB is sufficient for most servers
    • The size of the PVC can be changed by setting bot_data_size in the chatterbox config directory

Dimension storage :

  • Main:
    • File stored with uid=10005/gid=1000, sample config uses /mnt/dimension for single-node instances
      • The backing path for single node instances can be changed by setting bot_data_path in the dimension config directory
    • Storage space is constant to store a single file. 10M is sufficient for every server
      • The size of the PVC can be changed by setting bot_data_size in the dimension config directory
  • Postgres (in-cluster):
    • Files stored with uid=999/gid=999, sample config does not specify a default path for single-node instances
      • The backing path for single node instances can be changed by setting postgres_data_path in the dimension config directory
    • Storage space is proportional to the number of integration instances. 5GB is sufficient for most servers
      • The size of the PVC can be changed by setting postgres_storage_size in the dimension directory folder

Synapse storage:

  • Media:
    • File stored with uid=10991/gid=10991, sample config uses /mnt/data/synapse-media for single-node instances
      • The backing path for single node instances can be changed by setting media_host_data_path in parameters.yml
    • Storage space required grows with the number and size of uploaded media. 50GB is used as a starting point for PoC but can easily be exceeded depending on your use-case
      • The size of the PVC can be changed by setting media_size in parameters.yml

Postgres (in-cluster) storage:

  • Files stored with uid=999/gid=999, sample config uses /mnt/data/synapse-postgres for single-node instances
    • The backing path for single node instances can be changed by setting postgres_data_path in parameters.yml
  • Storage space is proportional to the activity on the homeserver. 5GB is used as a starting point for PoC but can easily be exceeded depending on traffic
    • The size of the PVC can be changed by setting postgres_storage_size in parameters.yml

Backup Guidance:

  • Adminbot:
    • Backups should be made by taking a snapshot of the PV (ideally) or rsyncing the backing directory to backup storage
  • Auditbot:
    • Backups should be made by taking a snapshot of the PV (ideally) or rsyncing the backing directory to backup storage
  • Chatterbox:
    • Backups should be made by taking a snapshot of the PV (ideally) or rsyncing the backing directory to backup storage
  • Dimension:
    • Backups should be made by taking a snapshot of the PV (ideally) or rsyncing the backing directory to backup storage
  • Synapse Media:
    • Backups should be made by taking a snapshot of the PV (ideally) or rsyncing the backing directory to backup storage
  • Postgres (in-cluster):
    • Backups should be made by kubectl -n element-onprem exec -it postgres-synapse-0 -- sh -c 'pg_dump -U $POSTGRES_USER $POSTGRES_DB' > synapse_postgres_backup_$(date +%Y%m%d-%H%M%S).sql
  • Postgres (external):
    • Backup procedures as per your DBA
  • Configuration:
    • Please ensure that your entire configuration directory (that contains at least parameters.yml & secrets.yml but may also include other sub-directories & configuration files) is regularly backed up
      • The suggested configuration path in Element's documentation is ~/.element-onpremise-config but could be anything. It is whatever directory you used with the installer.
Back to top