- 5 Minutes to read
CTERA BC/DR and Ransomware Solutions
- 5 Minutes to read
With CTERA you can protect and manage for unplanned disruptions, safeguarding your data and enabling users to continue driving your business. The following solutions should be incorporated in to the company business continuity plan.
During normal operations users access their files residing in a CTERA Edge Filer via network drives that map via the SMB protocol. In the background, the edge filer syncs, in near real time, any file changes to the CTERA Portal, creating another identical copy of the data.
Business continuity (BC) is a set of pre-defined plans that dictate how a company will continue to operate during a disruptive event. BC is proactive and generally refers to the processes and procedures an organization must implement to ensure that mission-critical functions can continue during and after a disaster.
Disaster recovery (DR) is a set of pre-defined procedures that dictate how a company plans to recover its IT infrastructure after a disruptive event. DR is reactive and comprises specific steps an organization must take to resume operations following an incident. Disaster recovery actions take place after the incident, and response times can range from seconds to days.
Whereas BC aims to keep operations running during the incident, DR focuses on restoring technology-based systems to the pre-failure state.
Ransomware is a type of cyber attack where malware designed to encrypt files on a device is used, rendering any files and the systems that rely on them unusable. Malicious actors then demand ransom in exchange for decryption.
Throughout this article, a portal or edge filer failure refers to failure due to unplanned events, from cyber attacks to human error to a natural disaster.
Automatic Ransomware Protection and Recovering Compromised Content
CTERA Edge Filers from version 7.6 include CTERA Ransom Protect to stop any ransomware attack as soon as it is identified. Taking proactive measures against ransomware attacks helps safeguard your data and ensures the continuity of your operations. CTERA Ransom Protect is able to detect and block ransomware attacks within seconds. For more details, see Ransomware Protection.
Continuing Operations After a Portal Fails
If a portal fails, end users can continue to work on any file that is not a stub file on the edge filer. The changed files will not be synced to the portal nor other edge filers connected to the portal until the portal has been recovered and syncing from the edge filer completed.
To ensure business continuity in case the portal fails, you need to back up the CTERA Portal servers and storage. You need to use third-party recovery tools to back up the CTERA Portal servers and storage.
You also need to back up the CTERA Portal database, see Configuring the CTERA Portal Database for Backup. To restore the CTERA Portal database from a backup requires at least one WAL file as well as the base backup. CTERA recommends enabling WAL archiving and keeping the WAL archives and a copy of the base backup at a different physical location to ensure recovery is possible even when the database becomes unusable in the primary location.
You can also use other PostgreSQL tools, or other third-party tools, to back up the CTERA portal database. For example, you can use the PostgreSQL tool pg_dump to back up the PostgreSQL database on the primary database server. pg_dump makes consistent backups even if the database is being used concurrently. pg_dump does not block other users accessing the database (readers or writers). Dumps can be output in script or archive file formats which should be saved to a different location.
- Script dumps are plain-text files containing the SQL commands required to reconstruct the database to the state it was in at the time it was saved. To restore from such a script, feed it to
psql. Script files can be used to reconstruct the database even on other machines.
- Archive file formats must be used with
pg_restoreto rebuild the database. When used with the archive file format,
For more details, refer to PostgreSQL documentation.
Using third-party tools can result in a recovery after a disaster not being consistent with the database, with the recovery being either older or newer than the database recovery.
If the portal recovery is older than the database, it will be missing some recent blocks. In this situation, you should rollback the database to an earlier point-in-time that matches the latest portal recovery.
If the portal recovery is newer than the database, since deleted blocks are kept for a minimum of 30 days and these blocks are never modified, as long as the database is no more than 30 days older, there will be no data loss.
Running CTERA FSCK is usually recommended following a disaster recovery. CTERA FSCK must be run only with approval from CTERA support.
Continuing Operations After an Edge Filer Fails
If an edge filer fails, end users want to continue with minimal downtime and as seamlessly as possible. CTERA provides the following options to maintain business continuity when an edge filer fails:
- Using a Second Edge Filer
With at least two CTERA Edge Filers you can use the second edge filer as a fail-safe device if the primary edge filer fails. The failover to the second edge filer is achieved automatically using Microsoft DFS. The edge filers must be configured in either caching or sync mode and each edge filer must be connected to the Windows Server running Active Directory with DFS.
Advantages: Immediate failover to the second edge filer with LAN access.
Disadvantages: An additional edge filer is required for failover.
- Directly to CTERA Portal
Until the faulty edge filer is replaced and fully operational, CTERA provides end users with access to their files in the CTERA Portal, also via mapped network drives, providing a very similar user experience to the edge filer access the end users are familiar with. Virtually immediate data-access recovery is enabled by diverting end users from the edge filer directly to the CTERA Portal, in order to access their files and folders.
Advantages: Immediate failover to the portal using WebDAV instead of SMB.
Disadvantages: During the failover period, access is over WAN and not LAN. A Cloud Drive Connect license must be purchased for every edge filer end user.