In previous posts, we shared instructions for setting up ΠΈ based on Veeam. Today we want to talk about backup using Commvault. There will be no instructions, but we will tell you what and how our clients are already backing up.
Storage system of a backup system based on Commvault in the OST-2 data center.
How does it work?
Commvault is a backup platform for applications, databases, file systems, virtual machines and physical servers. In this case, the initial data can be on any site: with us - on the client side, in another commercial data center or in the cloud.
The client installs an agent on backup objects - iData Agent - and configures it in accordance with the required backup policies. iData Agent collects the necessary data, compresses, deduplicates, encrypts and transfers them to the DataLine backup system.
Proxy servers ensure the connectivity of the client network and our network, the isolation of the channels through which data is transmitted.
On the DataLine side, data from the iData Agent receives Media Agent Server and sends it to storage on storage systems, tape libraries, etc. All this is managed by Commserve. In our configuration, the main control server is located on the OST site, and the backup server is located on the NORD site.
By default, client data is stored on one site, but you can organize backups to two locations at once or set up a schedule for transferring backups to a second site. This option is called βauxiliary copyβ. For example, all full backups at the end of the month will be automatically duplicated or moved to a second site.
Scheme of operation of the Commvault backup system.
The backup system works mainly on VMware virtualization: CommServe, Media Agent and Proxy servers are deployed on virtual machines. If the client uses our equipment, then the backups are placed on the Huawei OceanStor 5500 V3 storage system. To back up client storage systems, store backups on tape libraries, separate Media Agents on physical servers are used.
What is important to clients?
From our experience, customers who choose Commvault for backup pay attention to the following points.
Console. Customers want to manage backups themselves. All basic operations are available in the Commvault console:
- adding and removing servers for backup;
- setting up iData Agent;
- creation and manual start of tasks;
- self-restoration of backups;
- setting notifications about the status of backup tasks;
- differentiation of access to the console depending on the role and group of users.
Deduplication. Deduplication allows you to find and remove duplicate blocks of data during the backup process. Thus, it helps to save space on the storage system and reduces the amount of data transferred, reducing the requirements for bandwidth. Without deduplication, backups would take up two to three times the size of the original data.
In the case of Commvault, deduplication can be configured on the client side or on the Media Agent side. In the first case, non-unique data blocks will not even be transferred to the Media Agent Server. In the second, the repeating block is discarded and not written to the storage system.
Such block deduplication is based on hash functions. Each block is assigned a hash, which is stored in a hash table, a kind of database (Deduplication Database, DDB). When transmitting data, the hash is βpunchedβ through this base. If such a hash is already in the database, then the block is marked as non-unique and is not transferred to the Media Agent Server (in the first case) or written to the data storage system (in the second).
Thanks to deduplication, we can save up to 78% of storage space. Now 166,4 TB is stored on storage. Without deduplication, we would have to store 744 TB.
Possibility to differentiate rights. Commvault has the ability to set different levels of access to backup management. The so-called βrolesβ determine what actions will be user in relation to backup objects. For example, developers will only be able to restore a server with a database to a specific location, while an administrator will be able to run an out-of-order backup for the same server and add new users.
Encryption. You can encrypt data while backing up via Commvault in the following ways:
- on the side of the client agent: in this case, the data will be transferred to the backup system already in encrypted form;
- on the Media Agent side;
- at the channel level: data is encrypted on the side of the client agent and decrypted on the Media Agent Server.
Available encryption algorithms: Blowfish, GOST, Serpent, Twofish, 3-DES, AES (recommended by Commvault).
Some statistics
By mid-December, with the help of Commvault, we have 27 clients backing up. Most of them are retailers and financial institutions. The total amount of original copy data is 65 TB.
Approximately 4400 tasks are performed per day. Below are statistics on completed tasks for the last 16 days.
Most of all, Windows File System, SQL Server and Exchange databases are backed up through Commvault.
And now the promised cases. Although impersonal (NDA says hello :)), they give an idea for what and how customers use Commvault-based backup. Below are case studies for customers who use a single backup system, i.e. shared software, Media Agent Servers, and storage systems.
Case 1
Customer. Russian trading and manufacturing company of the confectionery market with a distributed network of branches throughout Russia.
Task.Organization of backup for Microsoft SQL databases, file servers, application servers, Exchange Online mailboxes.
The initial data is located in offices throughout Russia (more than 10 cities). You need to backup to the DataLine site with subsequent data recovery in any of the company's offices.
At the same time, the client wanted full self-management with access control.
Depth of storage - year. For Exchange Online, 3 months for online copies and a year for archives.
Decision. An additional copy was set up for the databases on the second site: the last full backup of the month is transferred to another site and stored there for a year.
The quality of the channels from the client's remote offices did not always allow backup and restore in the optimal time frame. To reduce the amount of transmitted traffic, deduplication was configured on the client side. Thanks to her, the time of a full backup became acceptable, taking into account the remoteness of the offices. For example, a full database backup of 131 GB from St. Petersburg is done in 16 minutes. From Yekaterinburg, a 340 GB database is backed up for 1 hour 45 minutes.
Through roles, the customer has configured different permissions for its developers: only backup or restore.
Case 2
Customer. Russian chain of children's goods stores.
Task. Organization of backup for:
a highly loaded MS SQL cluster based on 4 physical servers;
virtual machines with a website, application servers, 1C, Exchange and file servers.
The entire specified infrastructure of the client is spaced between the OST and NORD sites.
RPO for SQL servers - 30 minutes, for the rest - 1 day.
Storage depth - from 2 weeks to 30 days, depending on the type of data.
Decision. We chose a combination of solutions based on Veeam and Commvault. Veeam is used for file backups from our cloud. Database servers, Active Directory, mail and physical servers are backed up through Commvault.
To achieve high backup speed, the client allocated a separate network adapter on physical servers with MS SQL for backup tasks. A full backup of a 3,4 TB database takes 2 hours 20 minutes, and a full restore takes 5 hours 5 minutes.
The client had a large amount of initial data (nearly 18 TB). If the data were to be stacked onto a tape library, as the client had done before, then several dozen cartridges would be required. This would complicate the management of the client's entire backup system. Therefore, in the final implementation, the tape library was replaced by a storage system.
Case 3
Customer. Supermarket chain in the CIS
Task. The customer wanted to back up and restore SAP systems hosted in our cloud. For SAP HANA databases RPO=15 minutes, for virtual machines with application servers RPO=24 hours. Depth of storage - 30 days. In case of an accident RTO=1 hour, to restore a copy on demand RTO=4 hours.
Decision. For the HANA database, backups of DATA files and Log files were configured at specified intervals. Log files were archived every 15 minutes or when they reached a certain size.
To reduce the recovery time of the database, we set up two-level storage of backups based on the storage system and the tape library. On-line copies are added to the disks with the possibility of recovery at any time during the week. When the backup becomes older than 1 week, it is moved to the archive, to the tape library, where it is stored for another 30 days.
A full backup of one of the 181 GB databases is done in 1 hour 54 minutes.
When setting up backup, the SAP backint interface was used, which allows integrating third-party backup systems with SAP HANA Studio. Therefore, backups can be managed directly from the SAP console. This makes life easier for SAP administrators who don't have to get used to the new interface.
Backup management is also available to the client through the standard Commvault client console.
That's all for today. Ask questions in the comments.
Source: habr.com