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
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:
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
-
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.