Disaster Recovery Journey: A Real-Time Technical Session

A detailed journal of attempting to set up personal data backups – complete with all the technical roadblocks, troubleshooting, and lessons learned along the way.

Except for this line. This post was written with Claude.ai coming from my chat session. Notably the backup did not work as the files could not be seen in the finder. I spent about an hour on this. Also shortly after posting I tried some checks with ChatGPT , reformatting the drive again. What ultimately was happening was a big type-o. The volume naming in the disk utility tool did not allow me to have it be Lacie-Backup with a “p” so a different volume had been created and not the one on the disk. Once I remove the “p” all was well. In the end though also found that using the MacOS Journaled is preferred. I also set it as case sensitve since I have had some problems with case sensitivitiy and not being to edit / remove files from git because of the case sensitiivity issue as the files were not getting listed individually on my file system.

The Starting Point

Disaster recovery and continuity of business has been on my mind for a while. I’ve been thinking about the dependency on the resilience of cloud solutions – particularly Google for personal and business emails, and Apple and iCloud.

I haven’t been doing backups onto physical media that I myself store. I’ve been thinking about building a private data center for storage as well.

So I took some action and bought a 5TB drive. Now what do I do?

I’ve been using Claude more lately as it did a better job answering “How many edges are there in a 1000 piece puzzle” than ChatGPT did. It reminded me how much I used/relied on Claude projects for a solid 12 month period. So I’m back in Claude right now to see how it does in helping me navigate this backup process.

With most of my posts I want to advance some learning, so not only do I want to use the backup drive (the LaCie Rugged USB-C), but I also want to see if there are any systems automations that I should be looking at to make this backup process easier and repeatable.

The drive recommendation was given to me by someone I trust with my life and has done this research, so that saved a large portion of figuring this out.

The question: Can you help guide me on what I should do with this drive and back up my personal data that I have on my Google account and also with my iPhone?

The Technical Journey Begins

Initial Strategy Discussion

Claude recommended starting with the 3-2-1 backup rule: 3 copies of important data, on 2 different types of media, with 1 copy offsite. The plan was to:

Format the LaCie drive properly
Set up Google Drive backup using rclone
Create iPhone backup strategy
Explore automation options

Drive Formatting: The First Decision Point

The question: Mac or PC as primary system? Answer: Mac

Step-by-step formatting process:

Connect LaCie drive via USB-C
Open Disk Utility
Select the drive (not volumes underneath)
Click “Erase”
Choose format

First format choice: ExFAT (for cross-platform compatibility)

Name: “LaCie-Backup”
Format: ExFAT
Scheme: GUID Partition Map

Note: This choice would later prove problematic

Setting Up rclone for Google Drive

Installation process:

Check for Homebrew: brew --version ✓ (Homebrew 4.4.28 installed)
Install rclone: brew install rclone

Roadblock #1: Xcode license agreement

Error: You have not agreed to the Xcode license. Please resolve this by running:
sudo xcodebuild -license accept

Solution: Accept license, then continue with rclone installation.

Configuring rclone for Google Drive

Configuration steps:

rclone config
Choose “n” for new remote
Name it “gdrive”
Select option 22 (Google Drive) from the list
Leave client_id and client_secret blank
Choose full access (option 1)
Leave service_account_file blank
Skip advanced config
Use web browser authentication
Not a shared/team drive
Confirm and quit config

Testing the connection:

rclone lsd gdrive:

Success! Listed all Google Drive folders.

The First Backup Attempt

Command used:

rclone copy gdrive: /Volumes/LaCie-Backup/Google-Drive --progress -v

Roadblock #2: Permission errors

ERROR : Failed to copy: mkdir /Volumes/LaCie-Backup: permission denied

Multiple files failing with the same error.

Troubleshooting Permission Issues

Attempt 1: Create destination folder manually in Finder

Created “Google-Drive” folder on the drive
Still getting permission errors

Attempt 2: Check drive permissions

Right-click drive → Get Info
Shows “You have custom access”
Still permission issues persist

Attempt 3: Use sudo

sudo rclone copy gdrive: /Volumes/LaCie-Backup/Google-Drive --progress -v

Success! Files started copying, showing progress like:

INFO : file.docx: Copied (new)
Transferred: 294.606 MiB / 18.247 GiB, 2%, 10.339 MiB/s, ETA 29m38s

The Display Problem

Issue discovered: Files copying successfully but not appearing in Finder

Evidence that backup was working:

Terminal showed files being copied
Transfer speeds and progress indicators active
Command line ls commands showed files existed

Attempts to fix Finder display:

Command+R to refresh Finder – didn’t work
Navigate away and back – didn’t work
Open new Finder window – didn’t work
Check Disk Utility – also not updating disk usage correctly

Verification that files existed:

ls -la /Volumes/LaCie-Backup/Google-Drive

Showed folders and files with details, but Finder remained empty.

The File System Revelation

Discovery: Even Disk Utility wasn’t updating properly

Showed only 29.4 MB used when hundreds of MB had been copied
This suggested a deeper macOS/ExFAT compatibility issue

Decision point: Since this is Mac-only usage, would APFS be better?

System check:

sw_vers
ProductName: macOS
ProductVersion: 15.6.1

macOS Sequoia fully supports APFS – ExFAT was likely the problem.

Reformatting to APFS

Process: Same Disk Utility steps, but choose APFS instead of ExFAT

Expectation: APFS should have better macOS integration and real-time file display

Second Backup Attempt with APFS

Command: Same rclone command with sudo

Result: Still no files visible in Finder!

Verification: Command line showed files existed:

ls -la /Volumes/LaCie-Backup/
drwxr-xr-x@ 61 root  wheel  1952 [date] Google-Drive

The “61” indicated 61 items in the folder, and files were owned by “root”

The Ownership Problem

Theory: Files created by sudo rclone were owned by root, causing display issues

Attempt: Run rclone without sudo

rclone copy gdrive: /Volumes/LaCie-Backup/Google-Drive --progress -v

Result: Back to permission denied errors

Attempted fix: Change ownership

sudo chown -R [username]:staff /Volumes/LaCie-Backup

Still not working: Persistent permission and display issues

Final Debugging Attempt

Check what rclone sees:

rclone about /Volumes/LaCie-Backup/
Total:   228.274 GiB
Used:    210.618 GiB  
Free:    17.656 GiB

Puzzling result: Drive shows 210 GB used, but we had just started copying and hit errors immediately.

Session Conclusion

The session ended without a successful backup solution. Despite multiple approaches:

ExFAT formatting – permission and display issues
APFS formatting – same problems persisted
Various rclone permission approaches – inconsistent results
Troubleshooting ownership and drive permissions – no resolution

Technical Lessons from This Session

What Worked

Homebrew and rclone installation
Google Drive authentication and connection
Basic rclone functionality (could list and access files)

What Didn’t Work

File system choice didn’t resolve fundamental issues
Permission management was inconsistent
File visibility in macOS Finder remained problematic
Mixed results between command-line verification and GUI display

Key Technical Questions Raised

Why do files show as existing in command line but not in Finder?
Why does Disk Utility show different space usage than expected?
Is this an rclone-specific issue or broader macOS/external drive problem?
Would simpler backup methods (Google Takeout, Drive Desktop app) be more reliable?

Alternative Approaches for Future Sessions

Based on this experience, simpler alternatives to explore:

Google Takeout – Direct download approach
Google Drive Desktop + local backup tools
Time Machine to external drive (for overall system backup)
Manual verification of any backup method before relying on it

The Bigger Picture

This technical session reinforced that:

Perfect is the enemy of good in backup strategies
Starting simple might be better than advanced command-line tools
Testing and verification are crucial for any backup system
Documentation of both successes and failures helps future attempts

Sometimes the most valuable learning comes from what doesn’t work – this session provided plenty of material for understanding the complexities of modern backup solutions.

The journey continues…