简体中文 / [English]


Disaster Recovery Testing & Personal Backup Strategy Update

 
Exploration › Server Maintenance & Configuration

This article is currently an experimental machine translation and may contain errors. If anything is unclear, please refer to the original Chinese version. I am continuously working to improve the translation.

TLDR: It’s not enough to follow the 3-2-1 backup rule—you must also regularly test data recovery! Especially when dealing with large volumes of data, backup failures are inevitable. Only through testing can you ensure your backups are actually usable.

Below is my personal, stream-of-consciousness analysis…

0x00 Analyzing Existing Systems (Identifying What Needs Backup)

As a self-proclaimed amateur sysadmin, the systems I currently maintain fall into two main categories:

  1. Public services

  2. Private systems for personal use

    • HomeLab server (hosts most of my private services)
    • Various VPS instances across cloud providers
    • Laptop and smartphone

When setting up the “public services,” I prioritized high availability and low maintenance, leveraging technologies like static sites, serverless edge computing, and PaaS as much as possible. By outsourcing infrastructure management to third-party platforms, these services are inherently simple and reliable—there’s little need for traditional backups since deployments consist of build artifacts.

That leaves personal device data and server backups as the real challenge.
HomeLab with a ton of stuff that actually needs backing upHomeLab with a ton of stuff that actually needs backing up

0x01 Current Backup Strategy

I’ve mentioned bits and pieces of my backup setup in past posts.

No need to repeat myself—here’s a summary:

  • Android phone:

    • Photos synced to Google Photos
    • Minimal app data backed up via Google account (most apps store data online anyway)
    • QQ/WeChat chat history kept on laptop; no backup on phone
    • Other important files synced to HomeLab using Syncthing

  • Laptop:

    • Important files synced to HomeLab via Syncthing (mainly the Users folder, excluding unnecessary items)

  • Data from Google / GitHub etc.:

    • Manually exported periodically using Google Takeout / Export GitHub Data, then stored on HomeLab

  • HomeLab:

    • Receives synced files from phone and laptop via Syncthing, plus stores various cold data and programs.
    • Uses Duplicati to encrypt and back up everything to cloud storage.
      Duplicati backupDuplicati backup

0x02 Disaster Recovery Test

This backup setup has saved me before—during minor disasters (like accidentally deleting uncommitted Git files or bricking my phone while flashing a custom ROM).

But that doesn’t prove the reliability of my full backup system. In a larger disaster—say, total failure of my HomeLab’s disk array or physical damage to my laptop or phone—would my backups still hold up?

At the same time, data security and recovery convenience are two sides of a trade-off. A good backup strategy must balance “proving I’m me” with “preventing impersonation.”

So I began a long and painful data recovery test.

Assumption: I’ve lost all my electronic devices and storage media.

  1. Buy new phone and laptop, replace my SIM card. Using SMS, facial recognition, and friend-assisted verification, I can regain access to Alipay, WeChat, QQ, and other Chinese apps via phone number login. Most other domestic apps support similar recovery methods.
  2. Using SMS + email (via WeChat scan) + memorized Google password + one-time recovery codes written down on paper, I can definitely regain access to my Google account. This restores photos and app settings backed up to Google.
  3. Using recovery codes and master password (also written down), I regain access to my password manager. From there, I retrieve credentials for my backup cloud storage and the AES key used for encryption. I download and decrypt the backup, restoring my laptop and HomeLab data. All files recovered.

I tested every critical step on unfamiliar devices, different proxy nodes, and virtual machines. While testing password recovery, I also took the opportunity to rotate passwords. The process revealed several issues:

  • My Telegram account is linked to a GV number (not +86), which has since been deactivated. If I lose both phone and computer, I’d lose access to Telegram permanently.
  • WeChat’s password recovery is unnecessarily painful… For example, trying to reset via email might be blocked due to “security risks”…?? Then why even let me bind an email in the first place? WeChat could easily adopt Alibaba’s approach (facial verification + friend/email confirmation), but instead often forces manual appeals. While there’s no perfect workaround, I’ve decided to withdraw all balance from WeChat Pay to my bank account—just in case I get locked out and can’t access my funds.
    WeChat UX, questionable at bestWeChat UX, questionable at best
  • Duplicati is extremely slow when restoring large backups—unacceptably slow.

From a security standpoint, domestic apps mainly rely on phone number verification, while foreign services use password + 2FA. Here’s a quick security summary:

  • Password security: Random passwords from a password manager, with 2FA wherever possible. Cryptographic encryption ensures cloud backups remain secure.
  • Endpoint security: Never install suspicious software. Use antivirus tools. Endpoint security cannot be overstated—malware could read passwords or even unencrypted files directly from memory or SMS.
  • Social engineering defense: Machines don’t make mistakes, but people do. Stay vigilant. Don’t become the weakest link in your own security chain.

0x03 Optimizing the Setup

As you can see, the key recovery step in my simulation was retrieving data from the cloud backup—everything else was just regaining access to accounts and the password manager. So the reliability of this step is absolutely critical.

I spent a lot of time testing various cloud storage options.

https://forum.duplicati.com/t/big-comparison-borg-vs-restic-vs-arq-5-vs-duplicacy-vs-duplicati/9952

My HomeLab has roughly 5 million files, totaling ~4TB. The largest single file is a 1TB encrypted volume, while the smallest are numerous <4KB code snippets. This scale puts serious stress on the robustness of backup software.

After a week of testing, only Duplicati and Duplicacy successfully completed full backups to OneDrive. Many others either crashed or failed repeatedly.

Duplicati packs small files into blocks (configurable block size), which improves performance on backends unfriendly to small files. It offers faster uploads but relies on a local database and consumes significant CPU. File restoration, however, is painfully slow.

Duplicacy doesn’t use a local database, but creates many small files on the server, leading to higher failure rates and slower backups. On the plus side, restoration is relatively fast.

In the end, I decided to use both Duplicati and Duplicacy simultaneously, each encrypting and backing up to two separate OneDrive accounts:

  • E5-hosted OneDrive
  • Nanjing University’s 21Vianet OneDrive

Both are configured with email alerts for backup status.

This article is licensed under the CC BY-NC-SA 4.0 license.

Author: lyc8503, Article link: https://blog.lyc8503.net/en/post/disaster-recovery-test/
If this article was helpful or interesting to you, consider buy me a coffee¬_¬
Feel free to comment in English below o/