Source:SEP Cloud RDS

Other languages:

Deutsch
English

	WORK IN PROGRESS
	This article is in the initial stage and may be updated, replaced or deleted at any time. It is inappropriate to use this document as reference material as it is a work in progress and should be treated as such.

Welcome to the latest SEP sesam documentation version 4.4.3 Beefalo/4.4.3 Beefalo V2. For previous documentation version(s), check Documentation archive.

Overview

Additional resources

Check FAQ to find the answers to most common questions.

Problems? Check the Troubleshooting Guide.

The SEP Cloud RDS method enables you to permanently replicate block-based data from a local SEP Si3 deduplication store to a remote (offsite) Si3 deduplication store. However, this data can still be used directly due to the SEP sesam RDS (in this case SEP Cloud RDS Server) configured in the offsite location. For details on replication, see SEP Si3 Replication.

The dedicated connection between the SEP sesam Server and RDS ensures that data is separated between the individual connected clients and is end-to-end encrypted. Additionally, automated migration of the data to tape can be performed to avoid costs for tape drives and loaders.

This article describes different implementation scenarios for replicating to Cloud RDS Server. Note that you can implement compliance requirements easily without setting up a corresponding infrastructure locally.

Requirements

A VPN connection to establish a connection to the remote location.
A SEP sesam Si3R Storage Pool Replication license (includes a SEP Cloud RDS Server). If a volume-based license is used, the required licenses are already included. For details, see Licensing.

Implementation examples

In the below examples, four different implementation scenarios for replicating to Cloud RDS Server are described.

Scenario 1: Simple data replication

Selected data is permanently replicated to the remote (offsite) location and can be restored locally or at the remote location if required. Additionally, the block-based data can be migrated to tape as native file data.

Scenario 2: Replication of backed up virtual machines (VMs)

VMware

Selected VMs are permanently replicated to the remote location and then automatically restored to the local ESX data store. Additionally, the block-based data can be migrated to tape as native file data. For more details on VMware, see SEP sesam VMware documentation.

Citrix Hypervisor (XenServer)

Selected VMs are permanently replicated to the remote location and accessed via the local Citrix Xen pool. Additionally, the block-based data can be migrated to tape as native file data. For more details on Citrix, see SEP sesam Citrix Hypervisor documentation.

Scenario 3: Replication of backed up applications

Selected applications such as databases (e.g., Exchange, etc.) are permanently replicated to the remote location and directly accessible by mounting the local Si3 deduplication store via VFSL (Virtual File System Layer) without being restored first. Additionally, the block-based data can be migrated to tape as native file data.

	Note
	SEP sesam supports different applications to be used directly on the Si3 deduplication store without restoring the data first. For Si3 deduplication store requirements and configuration, see Configuring Si3 Deduplication Store.

Scenario 4: BaaS (Backup as a Service)

The managed service providers (MSP; SEP sesam partners) use SEP sesam for offering their customers Backup as a Service (BaaS). This means that the MSP is responsible for the complete management of the backup data. For such backups, a central SEP sesam Server is used in the data center, which performs a local backup (on-site) via distributed cloud RDS servers located at the respective customer's location. Additionally, the data is replicated to a dedicated cloud RDS server in the data center. These RDS servers run in the data center as a virtual machine on a server with the corresponding performance. Thus, data separation of the connected customers is ensured in this scenario as well.