Frequently Asked Questions About Solution Selection

Common questions about MLPS compliance, ransomware protection, Xinchuang adaptation, and disaster recovery architecture

What are the specific technical requirements of MLPS 2.0 Level 3 for data backup and disaster recovery?

The backup requirements of MLPS 2.0 Level 3 are distributed across multiple control points, including "Data Backup and Recovery," "Residual Information Protection," "Network Security," and "Host Security." The core can be summarized in four points: local data backup and recovery, off-site backup of important data, encryption and confidentiality of backup data, and regular recovery drills. The most common deductions come from having only local backups without off-site backups, and never performing recovery verification. Compliant technical measures typically involve CDP, immutable storage, and two sites with three data centers.

If ransomware encrypts production data, can backup data still be recovered? How do you prevent it?

Whether recovery is possible depends on whether the backup data was also encrypted. Ransomware protection typically relies on three layers of defense: first, immutable storage (WORM), where backup data cannot be tampered with after being written; second, Blu-ray storage with physical air-gap isolation, where offline data is beyond the reach of ransomware; third, integration with security capabilities, with automatic malware detection before backup. The Hbucloud backup appliance adopts these three layers of mechanisms, upgrading from "able to back up" to "backup means security."

How do you implement disaster recovery in a domestic Xinchuang environment?

The key to disaster recovery in Xinchuang environments is to confirm whether the vendor has original vendor-certified adaptation on domestic CPUs, operating systems, and databases, rather than "if it can connect, it is supported." Hot standby cloud has completed adaptation certification for 6 domestic CPUs: Kunpeng, Phytium, Hygon, Loongson, Zhaoxin, and Sunway; 10 domestic operating systems: Kylin Software, NeoKylin, UOS, openEuler, Zhongke Fangde, Ningsi, Puhua, Deepin, Red Flag, and Anolis OS; and 9 domestic databases: DM, Kingbase, GBase, ShenTong, HighGo, Yunhe Enmo, CS&S, EsgynDB, and Wanli.

Should the disaster recovery center be built in the same city or off-site? How should the distance be determined?

The MLPS standard itself does not specify "how many kilometers are required," only that it must be "off-site." Assessment practice and industry convention typically look at two points: the backup center and the production center are not in the same physical location, to avoid the impact of the same fire, power outage, or natural disaster; in terms of distance, industry practice usually recommends starting at tens of kilometers for same-city off-site, and for important systems, hundreds of kilometers or more across regions is recommended. Same-city addresses "speed," off-site addresses "distance," and the two are combined.

How should enterprises choose between a backup appliance and a pure software backup solution?

The essential difference between the two lies in deployment and operations responsibility. A backup appliance is an integrated hardware-software product, pre-installed at the factory, with a deployment cycle of hours, and operations handled by a single vendor; a pure software solution requires self-configured servers, takes days to deploy, separates hardware and software responsibilities, and has high operational complexity. When selecting, calculate the 3-5 year total cost of ownership (hardware + software licensing + operations + maintenance), rather than looking only at the initial purchase price. Core production data is usually better suited to an appliance.

Where are the most common point deductions in the disaster recovery portion of an MLPS assessment?

The most common deductions in MLPS Level 3 are not "failure to purchase backup equipment," but three things: having only local backups without off-site backups; never performing recovery drills, making backups "dead backups"; and backup data stored in plaintext without encryption. In addition, backup media being in the same room as production data, backup operation permissions not being minimized, and the lack of anti-deletion and anti-tampering mechanisms are also common deduction points.

How is the two sites with three data centers architecture specifically implemented? Is there a simplified version for small and medium-sized enterprises?

Two sites with three data centers refers to two regions and three data centers: the production center, the same-city disaster recovery center (addressing room-level failures), and the off-site disaster recovery center (addressing city-level disasters). The key to implementation is to first define RPO/RTO targets and then work backward to the architecture; for data synchronization, use synchronous replication for same-city and asynchronous replication for off-site, with CDP used for second-level RPO. The major costs lie in off-site link bandwidth and disaster recovery center construction, which can be controlled by reducing the configuration of the disaster recovery center, renting cloud resources off-site, and choosing maintenance-free integrated appliances.

How should backup data be encrypted and protected against tampering to meet audit requirements?

There are usually two aspects: for encryption, end-to-end AES-256 encryption of backup data and encrypted storage, meeting MLPS requirements for backup confidentiality; for anti-tampering, adopt immutable storage (WORM, write once read many), where backup data cannot be tampered with after being written, combined with Blu-ray storage physical air-gap offline archiving, forming the last layer of ransomware protection.