5 1 0:SEP Immutable Storage – SiS

From SEPsesam

Welcome to the latest SEP sesam documentation version 5.1.0 Apollon. For previous documentation version(s), check documentation archive.


Immutable storage is a very effective defense against ransomware attacks. As ransomware continues to evolve, backups become one of the targets of ransomware attacks. They can be deleted, altered or encrypted. Data can be lost or your company can be exposed to the threat of selling or sharing important company data or authentication information if the ransom is not paid.

SiS - SEP Immutable Storage

SEP sesam introduces SEP Immutable Storage, also called Si-Storage or SiS, to prevent attacks on backups. The idea behind SEP sesam Immutable Storage is that stored data remains completely static in its original and unchanged form throughout its lifetime. This means that businesses can quickly recover from a ransomware attack, even if they have lost access to their data and servers, by using stored data copies that have remained unchanged and intact to restore the entire operating environment.

SiS: For scenarios where administrator access to backup servers is compromised

Attackers typically compromise multiple accounts when attempting to gain access to administrator accounts to launch the ransomware. Targeted administrator accounts include backup administrator credentials, which provide a backdoor to access relevant environment data stored in a single location. The backup environment is a good place to start because the backup server has access to critical systems such as the virtualization environment and storage locations.

Therefore, SiS can play a critical role in a ransomware scenario. Even with full admin access to the SEP sesam backup server, the attackers cannot delete your backup data or modify or encrypt it in any way. So it does not matter if the attacker gained control over your backup servers, as you will always have the data that is not compromised and can be used to restore your entire environment.

For more details, see Ransomware Protection Best Practices.

Key benefits of SiS

Resistant to ransomware attacks
Immutability ensures that data is static, unalterable, and undeletable. Attackers therefore cannot modify, encrypt or delete it, even if they have gained access to your backup environment.
Resistant to human error and malicious insider threats
No one from the inside, regardless of their role in the organization and user status, cannot intentionally or accidentally tamper with or delete the data.
Meeting data security and compliance regulations
SiS can ensure that data is kept in compliance with industry and regulatory requirements by ensuring data permanence and authenticity. Immutability guarantees the integrity of data and its deletion after a specified period of time.
Legal hold
Ensures data authenticity for litigation requirements and secure storage of sensitive information for a set period of time.

Ensuring data immutability

SiS is based on Si3 store, a special type of data store that is typically required for Si3 deduplication. This is a new generation of Si3 data store that provides high performance for backup, restore and migration, as well as direct backup to S3. However, the new SiS functionality provides built-in security features to maintain data integrity, such as a WORM (Write-Once-Read-Many) function, definable immutability, audit logs, etc.

Based on the file protection service (FPS), which scans the file system and sets the "immutable" bit for all new objects, all data stored to SiS is marked immutable at the time of storage and can no longer be changed. No object stored on SiS can be modified in any way: It cannot be renamed or removed, no links can be created to these objects nor can its metadata be accessed or changed. The objects with immutable attributes can only be viewed in read-only mode.

SiS is a storage location that can be written to once and read as many times as needed. This applies to all media pools related to the SiS data store.

How it works

Linux server with SEP sesam
Si3 store must be set up on a dedicated Linux server with SEP sesam installed and directly connected to the SEP sesam Server via TCP network access to protect it from attacks via VM access. For all requirements for the Linux server, see Requirements below.
Protected remote access
If SSH access to the SiS server is enabled, completely different credentials than SEP sesam admin and server root must be used so that they cannot be compromised, and stored in a remote location that the SEP sesam Server cannot access. Robust authentication and authorization must be observed along with the principles of least privilege and separation of duties (SOD). It is recommended that SEP sesam components only communicate via a restricted TCP port using non-root credentials.
Data cannot be touched
Controlled access with flexibility of setting data retention time during which objects are WORM-protected and immutable, so access to the data is restricted – it cannot be modified, encrypted or deleted.
No access allowed
Once the immutability period is set, not even privileged accounts, such as an authorized backup administrator, can change, prematurely expire, or delete the retention.
Ensured data integrity
Each object stored on SiS has its own hash value based on its contents, ensuring its integrity. When updated data is stored in an immutable file system, it is stored in a new location in such a way that only the changed block is written and the file location metadata is updated. In this way, the data in an immutable file system remains the same while the metadata changes over time.
Immutability guaranteed by SiS
SiS immutability is based on the underlying filesystem. If old backup data is moved from SiS to another storage, e.g. to a cheaper archive storage in the cloud or to tape, SEP sesam no longer has ownership of the data, which is now in a domain of the chosen storage, and immutability is no longer guaranteed by SEP sesam.
SiS can be configured to comply with regulations and demonstrate the confidentiality, integrity, and security of the data stored on it. However, the management and security of SiS storage is the responsibility of the customer, while SEP can guarantee the immutability of SiS and its uninterrupted operation only if the configuration of SiS storage has been carried out correctly and all conditions (as described below) for SiS operation are met.

Supported task types

SiS supports all backup task types otherwise supported by SEP sesam:

  • All Path (filesystem) backups
  • All supported VM backup tasks: Citrix XEN Server/XCP-ng, Hyper-V,KVM QEMU, Nutanix AHV, OpenNebula, Oracle Linux Virtualization Manager (OLVM), Proxmox VE, Red Hat Virtualization (RHV), VMware vSphere
  • All supported database backups: IBM DB2, Informix, MS SQL, MySQL/MariaDB, Oracle, PostgreSQL, SAP, SAP ERP with MaxDB
  • All supported groupware backups: GroupWise, HCL (IBM) Domino, Kopano, MS Exchange, SharePoint

Configuring immutable storage

As Windows-based backup servers are more vulnerable to malicious attacks, SiS relies on a Linux system to store immutable copies of backup data. This requirement applies only to the SiS server, while the SEP sesam Server can be Windows or Linux, as described in the SEP sesam hardware requirements.

The following is a list of requirements for setting up the SiS Linux server and Si3.


SiS requires a dedicated Linux server running a 64-bit Linux distribution with the following characteristics:
  • One of the supported Linux versions: SLES 15, RHEL 8, RHEL 9, Debian 11, Debian 12
  • XFS
  • ext4
  • Support for the chattr command
  • Sufficient storage capacity (see Hardware requirements).

The SiS server does not work on older Linux versions such as SLES12, RHEL 7, and Debian 10.

  • Installed SEP sesam RDS package v. 5.1.0.x. For details, see SEP sesam Quick Install Guide.
    • For the minimum Si3 hardware requirements that apply to SEP sesam Si3 deduplication server, see Hardware requirements.
    • Additional amount of RAM is required for the Si3-NG data store. For details, see Configuring Si3 Deduplication Store: Required additional amount of RAM and CPU.
    • When estimating the maximum size of a deduplication store, you have to ensure that there is enough space available for dedup trash, otherwise the deduplication store will run out of space. You should calculate the required disk space based on a representative sample of your full backup and add the additional storage space equal to approximately 50% of the representative full backup.
  • Si3 runs on a Java platform and requires a Java Runtime Environment. The required Java version depends on the SEP sesam version.
  • Configuration of the SiS server must be done manually on the server itself, as explained in the following section.
SEP ensures the security of SiS storage and protects your data from various attacks only if the following is true: If SSH is used to access the SiS server, you must use unique credentials with restricted access that are completely different from SEP sesam admin and server root. These credentials must be stored in a location that the SEP sesam server cannot access.

Procedure overview

Two systems are involved in the configuration of an SiS:

  • The SiS server with internal hard disks, which provides the Si3 datastore as immutable storage.
  • A device server (RDS or SEP sesam Server) that accesses the Si3 datastore.
Although the SiS server has a SEP RTS package installed, it is neither created as a client nor as an RDS. It functions only as a proxy RDS.

The configuration procedure involves the following steps:

  1. Install the SEP RTS package and any service packs on the SiS, and enable the necessary ports.
  2. Run the sm_create_sds.sh config script on the SiS.
  3. In the GUI, create an Si3-NG DeduplicationStore, select 'Si3 Appliance' as the type in the backend and specify the SiS data.
  4. Select the backup server or another RDS as the device server.

Configuration: On dedicated SiS Linux server

  1. Download the SEP sesam RDS package v. 5.0.0.x from the SEP Download Center: Make sure you download the correct file for your processor type. Install the RTS package on the Linux server as described in Linux Installation.
  2. To set up the storage path for the SiS data store, go to the drive view in the SEP sesam UI and find the next free drive number on SEP sesam Server. Note that it can be located between two existing drive numbers. Then open the shell on the SiS server and execute:
# sm_create_sds.sh -C <sesam server> -E <days> -d <drive number> <datastore name> <storage path>
  -E <immutable period in days>
  -d <drive number>

SiS immutability period

The immutability period means that all savesets on the SiS storage are immutable for the configured number of days. The immutability period specified in the SiS storage settings begins the moment a saveset is written to storage.

In the following example, the immutability period on a dedicated SiS Linux server is set to 30 days: -E 30. This should be enough to protect a typical backup chain, since ransomware may already be in your systems before it strikes.


#/opt/sesam/bin/sesam/sm_create_sds.sh -C sesamx.sep.de -E 30 -d 20 si3 /data

In this case, SEP recommends the following retention for a backup chain: create a media pool MONTH with a retention time of 31 days (leave an extra day: SiS immutability period + 1 day, where SiS immutability period is the number of days that you specified on the SiS storage side) and create a seven-day policy for FULL INCR. Note that as backups to SiS are protected and are therefore impervious to any change, it is very important that your backup chain configuration is synchronized with the SiS immutability period setting so that your active backup chain protected. For more details, see the section Creating immutability and retention policies.

After the immutability period has expired, the backups are deleted from the SiS storage.

Firewall configuration

To accept a connection from the SEP sesam Server, the correct port must be open for the SiS service. The default port is 11701 + drive number (as configured above). Add (sum) the assigned drive number (from the first step) to the default port number.

Example for drive number 20: 11701 + 20 = 11721
This port must be open in the firewall.

Example for Debian Linux:

firewall-cmd --zone=public --add-port 11721/tcp -permanent
firewall-cmd -reload
firewall-cmd --list-ports (returns at least port 11721/tcp)

Configuration: On SEP sesam Server

For security reasons, make sure you do not add the dedicated SiS Linux server as SEP sesam Client!

Open the GUI and create a new Si3 data store with the same name as used on RDS:

  1. In the Main selection -> Components, click Data Stores to display the data store content frame.
  2. From the Data Stores menu, select New Data Store. A New Data Store dialog appears.
  3. Under Data store properties, enter the name you previously used on RDS as the name for the Si3 deduplication store. Entering the name also creates the drive group name for your Si3 deduplication store in the Create new drive group field.
  4. From the Store type drop-down list, select SEP Si3 NG Deduplication Store.

  5. The Create drive and Create second drive options are enabled under the Drive parameter properties. The predefined value for the drive is automatically set in the Drive number field. Change the drive number and enter the drive number you selected in the SiS configuration.
  6. The name in the Create new drive group field is already created. You can change it by simply entering a new name.
  7. The predefined number of channels is already set in the Max. channels drop-down list. The number of available channels depends on your SEP sesam Server package. For details on licensing, see Licensing.
  8. From the Device server drop-down list, select the device server for your data store.
  9. Switch to the Storage Backend tab and and configure the credentials by selecting New. Name the new Credential set and set the SiS host to the hostname or IP number of RDS.
  10. Go back to Properties to configure the Path field. Use the large Browse button to locate the server and browse to the location of your data store that you set when configuring SiS. The New data store information window appears with predefined recommended values for your data store size. Click OK to confirm the selected location and recommended size values.
    You cannot browse the location if you have not configured the credentials as described in the previous step.

    You can modify your data store size later under the Size properties. You can also enter the following values manually, depending on the free disk space on SiS.

    • Capacity: Set the size (in GB/GiB) of the storage for backups.
    • High watermark: The HWM defines the upper value for the used storage space. When this value is reached, the status of a data store changes from OK to Warning, but backups are still performed. Make sure that you provide enough storage space for your backed up data.

    Click OK to configure your data store. You will be prompted to immediately create a new media pool for it. Click Yes and follow the procedure described in the following section Creating immutability and retention policies.

Creating immutability and retention policies

By selecting the immutability period, you define how long objects are securely retained before they are deleted. The immutability of backed up data is achieved by completely restricting access to the data so that it cannot be modified. This means that the immutability policy that you create on SiS storage cannot be modified.

SiS immutability period and media pool retention time

When configuring SiS storage, the retention time is actually set twice:

  1. First on the SiS storage itself. The SiS immutability parameter is actually the immutability duration parameter and specifies how long the savesets stored on it are immutable and therefore cannot be deleted, moved, or modified in any way. See the example above.
    The SiS immutability setting can only be configured on the SiS storage itself and cannot be modified via SEP sesam UI. The immutability period for data on SiS is applied in days since the policy was created. It is designed to enforce compliance with set rules and cannot be changed by anyone until the immutability period has expired.
  2. The second parameter is the media pool retention time. It defines the period of time for which all savesets in the respective media pool are available for reading, so that the savesets are preserved and available for restore, migration, or replication. This period should be longer than the SIS storage immutability period.
    Once the immutability period for the SIS storage expires, the savesets are still available, but the additional protection against accidental deletion or modification of the savesets is no longer provided.

Creating a media pool and media pool retention policy

As SEP sesam data stores use media pools for backup to disks (in this case, a SiS storage), you must first configure a dedicated media pool for it and set a media pool retention policy. Note that you can create as many media pools for a data store as you need.

  1. In the New Media Pool window, enter a name for the media pool, select a drive group (which you created earlier in SiS data store configuration) and set the Retention time in days. This retention time specifies the number of days for which the data is protected from writing by SEP sesam, thus preserving the savesets and keeping them available for restore. The retention time period starts with the date a saveset is written to the media and defines the expiration date (EOL) after which the saveset may be deleted.
    To protect at least the complete last backup chain, a minimum level of protection specified in the media pool retention policy should always be set in accordance with the SiS immutability period. Ensure that you set such retention settings that allow you to protect the whole backup chain on the SiS storage. Keep in mind the retention time specified at the media pool level should be higher than the SiS immutability retention. See the example above.
  2. For more details on configuring a media pool, see Configuring media pools for data stores.

  3. Once you have set up your media pool, you have to create a backup task, create a schedule, and link a backup event with it. For details, see Standard Backup Procedure.

Security considerations

Time settings
The exact time is crucial for the immutability flag. This is checked on the SiS Linux server to prevent potential attackers from changing the time and bypassing the configured immutability time. So it is imperative to ensure that the time is correct. It is recommended to use a reliable NTP server for time synchronization of your dedicated SiS Linux server.
Additional repositories on the dedicated Linux server
Having immutable and non-immutable data stores or other data repositories on the same Linux server is not supported! Such a configuration poses additional security risks and is therefore not supported.

FAQ and troubleshooting

For answers to most frequent questions see FAQ - SEP Immutable Storage (SiS). If you have problems using Si3 datastore or related issues, see also Troubleshooting Si3 Deduplication.

See also

Audit LoggingRansomware Protection Best PracticesAbout Authentication and AuthorizationBackup Strategy Best PracticesConfiguring RDS (Linux example)

Copyright © SEP AG 1999-2024. All rights reserved.
Any form of reproduction of the contents or parts of this manual is allowed only with the express written permission from SEP AG. When compiling and designing user documentation SEP AG uses great diligence and attempts to deliver accurate and correct information. However, SEP AG cannot issue a guarantee for the contents of this manual.