サポートと今すぐチャット
サポートとのチャット

QoreStor 7.1.3 - User Guide

Introducing QoreStor Accessing QoreStor Configuring QoreStor settings
Licensing QoreStor Configuring SAML Configuring an SSL Certificate for your QoreStor System Configuring Active Directory settings Understanding system operation scheduling Configuring Secure Connect Enabling MultiConnect Configuring and using Rapid NFS and Rapid CIFS Configuring and using VTL Configuring and Using Encryption at Rest Configuring and using the Recycle Bin Configuring Cloud Reader Configuring RDA immutability
Managing containers Managing local storage Managing cloud storage Managing replications Managing users Monitoring the QoreStor system Managing QoreStor remotely Support, maintenance, and troubleshooting Security recommendations guide About us

Replication

Replication is the process by which key data is saved from storage locations, with the goal of maintaining consistency between redundant resources in data storage environments. Data replication improves the level of fault-tolerance, which improves the reliability of maintaining saved data and permits accessibility to the same stored data.

QoreStor uses an active form of replication that lets you configure a primary-backup scheme. During replication, the system processes data storage requests from a specified source to a specified replica target, which acts as a replica of the original source data.

NOTE: QoreStor includes version checking that limits replication only between other QoreStor instances or DR Series systems that run a compatible software release version. If versions are incompatible, the administrator is notified by an event.

Replicas are read-only and are updated with new or unique data during scheduled or manual replications. QoreStor can be considered to act as a form of a storage replication process in which the backup and deduplication data is replicated in real-time or via a scheduled window in a network environment. In a replication relationship between two or three QoreStor instances or DR Series systems, this means that a relationship exists between a number of systems. One system acts as the source and the other as a replica.

Replication is done at the container level and is one directional from source to replica; however, since replication is done at the container level you can set up various containers to meet your specific replication requirements for your specific workflow. This form of replication is supported for the CIFS, NFS, Rapid CIFS, and Rapid NFS, RDA, and Object protocols and is fully handled by QoreStor.

QoreStor supports replication seeding, which provides the ability to create a local seed and place it in a remote system. The seed backup is a process on the source QoreStor system, which collects all of the unique data chunks from the containers and stores them on the target device. This is helpful if you have a new replication target to set up, the amount of data to be replicated is very large, and the network bandwidth is low.

NOTE: The storage capacity of the target QoreStor system is directly affected by the number of source systems writing to its containers, and by the amount being written by each of the source systems.

If the source and target systems are in different Active Directory (AD) domains, then the data that resides on the target system may not be accessible. When AD is used to perform authentication forQoreStor systems, the AD information is saved with the file. This can act to restrict user access to the data based on the type of AD permissions that are in place.

NOTE: This same authentication information is replicated to the target QoreStor system when you have replication configured. To prevent domain access issues, ensure that both the target and source systems reside in the same Active Directory domain.

Reverse replication

The concept of reverse replication is not a supported operation on QoreStor. This is because replica containers are always in a R-O (read-only) mode on QoreStor, thus making write operations a non-supported operation.

Alternate ways to retrieve data

Under very specific conditions, it could be possible for replica containers to support a type of write operation whose sole function is to restore data from an archival target. For example, data could be replicated back to the remote site where a data management application (DMA), or backup software, is connected to allow this data to be restored directly.

This specific type of case applies only to configurations where data is backed up from a remote location to a local container, and then replicated over a WAN to a replica container that is backed up to tape. The data needs to be restored from the tape backup to the original location; first back to QoreStor replica container, and then back to the original source location of the data on the other side of the WAN link.

NOTE: If you choose to use this alternate workaround method, you must set up a new data storage unit in your DMA, and import the images before a restore to the original location can occur.

To leverage this type of deduplication across the WAN, complete the following:

  1. Make sure that the replication operation has completed (between source and target).
  2. Delete the current replication relationship, and re-create a replication relationship (reversing the source and target roles).
  3. Restore data to the original source container (now the target).
  4. Make sure that the replication operation has completed.
  5. Delete the replication relationship and re-create a replication relationship (restoring original source and target destinations).

Under this scenario, a fraction of the data to be recovered is sent across the WAN link. This could speed up a remote restore significantly. However, there are some downsides to this type of scenario:

  • If step 1 is not followed correctly, any changes not fully replicated are lost.
  • During steps 2 and 3, any data that is written to the original QoreStor source container may be lost.
  • During step 4, if the data is not fully replicated back before the switch is made, it may be lost.
Alternatively, you could still support this type of effort by completing the following:
  1. Create a new container on the target QoreStor instance.
  2. Set up replication from this container back to the source QoreStor system container.
  3. Set up a new disk storage unit in the DMA and make sure that the DMA is aware of any new images.
  4. Import the old images back into the DMA from the target QoreStor instance (the original source location).
  5. Use a new disk storage unit in the DMA, and then restore the data back to the original client.

Reverse replication: alternate method

For an alternate method of reverse replication, complete the following steps:

  1. Create a new container on the target QoreStor instance.
  2. Set up replication from this container back to the source QoreStor container.
  3. Set up a new disk storage unit in your Data Management Application (DMA) and make sure that the DMA is aware of any new images.
  4. Import the old images back into the DMA from the target QoreStor instance (the original source location).
  5. Use a new disk storage unit in the DMA, and then restore the data back to the original client.

Performance tier

In situations where certain workloads have requirements for faster recovery, QoreStor allows you to write these workloads to a performance tier to enable faster read back unaffected by activity in other QoreStor Storage Groups. By utilizing a performance tier, you are able to maximize the value of higher-performing storage by ensuring that only the most critical workloads are written to it.

To create a QoreStor performance tier, you must create a physical volume comprised of high-performing storage (such as SSD) and then create a QoreStor storage group mapped to that volume. Containers created on that storage group will write and read from high-performance storage exclusively and will be isolated from read activity on other volumes.

関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択