Finally Cleaning Up Dropbox: Moving Almost a TB to Google Drive with rclone

I’ve had a Dropbox account for years. Like a lot of people, I started using it when it was one of the easiest ways to sync files across machines and keep important stuff backed up.

Over time, that Dropbox account became a bit of a digital attic. Old recordings, videos from various bands over the past 12 years, charts, rehearsal tracks, PDFs, installers, and all kinds of things I didn’t necessarily need every day, but definitely didn’t want to lose.

The problem was that I was paying about $20/month to keep it around.

That might not sound like a lot, but it adds up to about $240/year. And since I already pay for Google storage and iCloud storage, it seemed silly to keep paying for Dropbox just because I had never gotten around to cleaning it up.

So the question became:

How do I move almost a TB of data from Dropbox to Google Drive without downloading it all locally and uploading it again?

Because honestly, who has the time or local disk space for that?

The Problem

My Dropbox account had roughly 734 GB of data in it.

My Mac only had about 30 GB of free space.

So the normal approach was not going to work.

I could not just sync everything locally from Dropbox and then drag it into Google Drive. There simply wasn’t enough room on the Mac.

I looked at a few paid cloud migration services. They would have worked, but the plan I needed was going to cost more than I wanted to spend for a one-time migration.

After a quick conversation with ChatGPT, I decided to use rclone.

rclone is a free command-line tool that can copy data between cloud providers. In my case, I used it to copy files directly from Dropbox to Google Drive.

The best part?

The data never had to live on my Mac.

My Mac simply coordinated the transfer.

Dropbox → Google Drive

No giant local download. No external hard drive. No paid migration service.

Step 1: Install rclone on macOS

I already had Homebrew installed, so installing rclone was simple.

Open Terminal and run:

brew install rclone

Verify the install:

rclone version

You should see version information similar to:

rclone v1.74.3

Step 2: Configure the Dropbox Remote

Run:

rclone config

Choose:

n

for a new remote.

Name it:

dropbox

When prompted for the storage type, choose Dropbox. In my version of rclone, Dropbox was option 15.

15 / Dropbox
\ (dropbox)

For the client ID and client secret, I just pressed Enter to accept the defaults.

When prompted to use automatic configuration, choose:

y

A browser window opened and asked me to authorize Dropbox. Once I approved it, the browser showed:

Success!
All done. Please go back to rclone.

Back in Terminal, I saved the remote.

Step 3: Configure the Google Drive Remote

Run the config again:

rclone config

Choose:

n

Name this remote:

gdrive

When prompted for storage type, choose Google Drive. In my version of rclone, it was option 24.

24 / Google Drive
\ (drive)

Again, I left the client ID and client secret blank by pressing Enter.

For scope, I selected full access:

1

For the service account file, I pressed Enter.

When prompted for advanced configuration:

n

When prompted to use the browser for authentication:

y

This opened a Google authentication window.

This part is important. I made sure to authenticate with the Google account I actually wanted to use as the destination:

dave@medfordband.com

That is my personal Google Workspace account, and it already had enough storage available.

After approving the permissions, I saved the remote.

Step 4: Verify Both Remotes

To confirm both remotes were configured, I ran:

rclone listremotes

The output showed:

dropbox:
gdrive:

Then I verified that I could see files on both sides.

rclone lsd dropbox:

and:

rclone lsd gdrive:

Dropbox showed my old folders. Google Drive showed my existing Google Drive folders.

At this point, I knew the connections were working.

Step 5: Run a Small Test Copy

Before moving hundreds of gigabytes, I tested with a small folder.

rclone copy "dropbox:Scripts" "gdrive:Dropbox Migration/Scripts" --progress

That completed successfully.

The output showed that 64 files had transferred.

Good enough for me.

Step 6: Keep the Mac Awake

Since this was going to run for hours, I opened a second Terminal window and ran:

caffeinate -d

That command does not return any fancy output. It just sits there.

That is normal.

It keeps the Mac awake while the transfer runs. Leave that Terminal window open until the migration finishes.

Step 7: Start the Full Dropbox to Google Drive Migration

In the original Terminal window, I started the full copy:

rclone copy dropbox: "gdrive:Dropbox Migration" --progress --transfers 8 --checkers 16

That command copies everything from the root of Dropbox into a folder in Google Drive called:

Dropbox Migration

The --progress option shows live progress.

The --transfers 8 option allows multiple files to transfer at once.

The --checkers 16 option lets rclone check files more aggressively while copying.

Once it started, I could see files actively moving.

Transferred: 252.220 MiB / 449.554 GiB
ETA 5h23m54s

At that point, I knew the migration was off and running.

What If It Gets Interrupted?

One nice thing about rclone is that it is resumable.

If the Mac reboots, the network drops, or the process gets interrupted, just run the same command again:

rclone copy dropbox: "gdrive:Dropbox Migration" --progress --transfers 8 --checkers 16

rclone will skip files that already copied successfully and continue with the rest.

Step 8: Verify the Migration

After the copy finishes, compare the source and destination sizes.

Check Dropbox:

rclone size dropbox:

Check Google Drive:

rclone size "gdrive:Dropbox Migration"

The numbers should be reasonably close.

There may be some differences depending on shared folders, shortcuts, Dropbox backups, Google Photos references, or files that are counted differently by each provider.

Why I Like This Approach

This solved a very practical problem.

I had a lot of history in Dropbox that I did not want to lose. Old band recordings. Videos. Rehearsals. Charts. Random files collected over more than a decade.

But I was tired of spending $20/month just to keep that old account alive.

Since I already pay for Google storage, consolidating everything into my Google account makes sense.

The other options were not great:

Download everything locally? Not enough disk space.

Upload it all again manually? No thanks.

Pay for a migration service? Maybe, but I only needed this once.

With rclone, I was able to do the migration for free, without needing a 1 TB local disk, and without moving the data through my Mac’s storage.

Final Thoughts

This is one of those little cleanup projects I should have done years ago.

Dropbox served its purpose, but now I’ll save about $20/month and have my old data consolidated in Google Drive where I already have plenty of storage.

If you have an old cloud storage account hanging around just because you’re afraid to lose what’s in it, rclone is worth a look.

It is not as fancy as a commercial migration tool, but it gets the job done.

And sometimes that is exactly what you need.

Finally Cleaning Up Dropbox: Moving Almost a TB to Google Drive with rclone

Extending a SQL Server Failover Cluster Across Regions in  Google Cloud Platform (GCP)

I was the principal author of this SIOS whitepaper, which describes how to build a 2-node SQL Server cluster in Google Cloud Platform (GCP) spanning multiple zones. Today, I’ll explain how to extend this cluster by adding a third node in a different GCP region.

Assuming you’ve completed all the steps in the referenced documentation, here’s how to proceed:


1. Create Subnet

Create a new subnet in the additional region.

gcloud compute networks subnets create wsfcnetsub1 \
    --network wsfcnet \
    --region us-west1 \
    --range 10.1.0.0/16

2. Configure Firewall for Internal Communication

Open up firewall rules to allow internal communication on the new subnet.

gcloud compute firewall-rules create allow-all-subnet-10-1 \
    --network wsfcnet \
    --allow all \
    --source-ranges 10.1.0.0/16

3. Verify Available Zones

Check which zones exist in the new region (e.g., us-west1).

gcloud compute zones list \
    --filter="region:(us-west1)" \
    --format="value(name)"

4. Check VM Types Supporting Local SSD

Find the VM types that support local SSD in your target zone.

gcloud compute machine-types list \
    --zones us-west1-a \
    --filter="guestCpus>0 AND name:(n2 n2-highmem n2-highcpu c2 e2-custom e2-custom-memory e2-custom-cpu)" \
    --sort-by=guestCpus

5. Create New VM Instance

Create the new VM in the chosen zone with appropriate settings.

gcloud compute instances create wsfc-3 \
 --zone us-west1-a \
 --machine-type n2-standard-2 \
 --image-project windows-cloud \
 --image-family windows-2016 \
 --scopes https://www.googleapis.com/auth/compute \
 --can-ip-forward \
 --private-network-ip 10.1.0.4 \
 --network wsfcnet \
 --subnet wsfcnetsub1 \
 --metadata enable-wsfc=true \
 --local-ssd interface=nvme \
 --create-disk=auto-delete=yes,boot=no,device-name=extradisk1,size=1,type=pd-standard

6. Set Windows Password

Set a Windows password for accessing the new VM.

gcloud compute reset-windows-password wsfc-3 \
    --zone us-west1-a \
    --user david

7. Configure Windows Networking

On wsfc-3, run these PowerShell commands to configure the network.

# Remove existing DHCP configuration
Remove-NetIPAddress -InterfaceAlias "Ethernet 2" -AddressFamily IPv4 -Confirm:$false
# Set static IP
New-NetIPAddress -InterfaceAlias "Ethernet 2" -IPAddress 10.1.0.4 -PrefixLength 16 -DefaultGateway 10.1.0.1
# Set DNS server
Set-DnsClientServerAddress -InterfaceAlias "Ethernet 2" -ServerAddresses 10.0.0.6

8. Bring Extra Storage Online

Run these PowerShell commands to initialize and format the additional storage.

# Identify the new disk
$disks = Get-Disk | Where-Object IsOffline -Eq $false
$newDisk = $disks | Where-Object PartitionStyle -Eq 'RAW'
# Initialize and format new disk
Initialize-Disk -Number $newDisk.Number -PartitionStyle MBR
New-Partition -DiskNumber $newDisk.Number -UseMaximumSize -AssignDriveLetter | Format-Volume -FileSystem NTFS -NewFileSystemLabel "ExtraDisk"

9. Ensure Local SSD Attaches on Startup

Use this script to format and mount the local SSD on startup. Call it AttachSSD.ps1 and save it here. C:\Scripts\AttachSSD.ps1

$diskNumber = 0
$driveLetter = "F"
# Check drive letter availability
if (Get-PSDrive -Name $driveLetter -ErrorAction SilentlyContinue) {
    exit
}
# Initialize and format if RAW
$disk = Get-Disk -Number $diskNumber -ErrorAction SilentlyContinue
while (-not $disk) {

    Start-Sleep -Seconds 5

    $disk = Get-Disk -Number $diskNumber -ErrorAction SilentlyContinue

}
if ($disk.PartitionStyle -eq 'RAW') {

    Initialize-Disk -Number $diskNumber -PartitionStyle GPT

}

$existingPartition = Get-Partition -DiskNumber $diskNumber -ErrorAction SilentlyContinue

if (-not $existingPartition) {

    $partition = New-Partition -DiskNumber $diskNumber -UseMaximumSize -AssignDriveLetter

    Format-Volume -DriveLetter $partition.DriveLetter -FileSystem NTFS -NewFileSystemLabel "LocalSSD"

    Set-Partition -DriveLetter $partition.DriveLetter -NewDriveLetter $driveLetter

}

Schedule Script to Run at Startup:

$taskName = "InitializeLocalSSD"
$scriptPath = "C:\Scripts\AttachSSD.ps1"
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NoProfile -ExecutionPolicy Bypass -File `"$scriptPath`""

$trigger = New-ScheduledTaskTrigger -AtStartup

$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest

Register-ScheduledTask -TaskName $taskName -Action $action -Trigger $trigger -Principal $principal

10. Join the Domain

Join the new server to the domain.

$domain = "datakeeper.local"
$username = "administrator@datakeeper.local"

$password = "YourPassword!"

$securePassword = ConvertTo-SecureString $password -AsPlainText -Force

$credential = New-Object System.Management.Automation.PSCredential ($username, $securePassword)

Add-Computer -DomainName $domain -Credential $credential -Force


11. Add a new mirror to the existing Datakeeper job

Follow the screenshots below to extend the existing DataKeeper job to the new server.


12. Install Windows Failover Clustering and add to the cluster

Install clustering tools and add the node to the cluster.

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
Add-ClusterNode -Cluster fileserver.datakeeper.local -Name wsfc-3

Test-Cluster -Name fileserver.datakeeper.local

Note: Adding the node through the WSFC UI may be necessary if there’s a load balancer issue with the cluster name.

13. Install SQL Server on the new cluster node

Run SQL Server setup and choose add node to existing cluster installation option. https://learn.microsoft.com/en-us/sql/sql-server/failover-clusters/install/add-or-remove-nodes-in-a-sql-server-failover-cluster-setup?view=sql-server-ver16


14. Create New Load Balancer Rules

Configure load balancing to allow access across regions.

gcloud compute instance-groups unmanaged create wsfc-group-3 --zone=us-west1-a

gcloud compute instance-groups unmanaged add-instances wsfc-group-3 --instances wsfc-3 --zone us-west1-a

# Set environment variables
export REGION="us-west1"
export NETWORK="wsfcnet"
export SUBNET="wsfcnetsub1"
export LB_NAME="swfc-lbwest"
export HEALTH_CHECK_NAME="wsfc-hc-west"
export HEALTH_CHECK_PORT="59998"
export BACKEND_PORTS="1433"
export BACKEND_IP="10.1.0.9"
export BACKEND_RESPONSE="1"
export LB_INTERNAL_IP="10.1.0.9"

# Step 1: Create Health Check
gcloud compute health-checks create tcp $HEALTH_CHECK_NAME \
--region=$REGION \
--port=$HEALTH_CHECK_PORT \
--check-interval=2s \
--timeout=1s \
--unhealthy-threshold=2 \
--healthy-threshold=2

# Step 2: Create Backend Service
gcloud compute backend-services create $LB_NAME-backend \
--load-balancing-scheme=INTERNAL \
--protocol=TCP \
--region=$REGION \
--health-checks=$HEALTH_CHECK_NAME \
--health-checks-region=$REGION

# Step 3: Add Backend Instance Group
gcloud compute backend-services add-backend $LB_NAME-backend \
--instance-group=wsfc-group-3 \
--instance-group-zone=us-west1-a \
--region=$REGION

# Step 4: Create Frontend Configuration (Forwarding Rule)
gcloud compute forwarding-rules create $LB_NAME \
--load-balancing-scheme=INTERNAL \
--ports=$BACKEND_PORTS \
--network=$NETWORK \
--subnet=$SUBNET \
--region=$REGION \
--backend-service=$LB_NAME-backend \
--ip-protocol=TCP \
--address=$LB_INTERNAL_IP
--allow-global-access

Update the original load balancing forwarding rule to allow global access

gcloud compute forwarding-rules update wsfc-lb --region=us-east1 --allow-global-access

This completes the steps to extend your SQL Server cluster across multiple GCP regions. In the future I’ll probably write a single comprehensive how-to guide, but for now, let me know if you have any questions!

Extending a SQL Server Failover Cluster Across Regions in  Google Cloud Platform (GCP)

The Importance of Patch Management to Avoid Downtime

A recent Microsoft outage caused by a bad patch pushed out to Windows instances managed by CrowdStrike has thrown a spotlight on the critical importance of effective patch management. This incident impacted numerous businesses, including airlines, banks, 911 services, and many others. It serves as a stark reminder of why meticulous planning and execution of updates are vital to avoid costly downtime.

The Necessity of Pre-Production Testing

One of the cardinal rules of patch management is to test updates in a pre-production environment before deploying them to production systems. This approach allows IT teams to identify potential issues and conflicts that may arise from the update, ensuring that the actual deployment does not disrupt business operations. By simulating the production environment, organizations can validate the stability and compatibility of the updates, significantly reducing the risk of unforeseen failures.

Fast-Tracking Security Updates with Caution

While regular updates should follow a structured testing process, security updates that address zero-day exploits present a different challenge. These updates often need to be fast-tracked to mitigate the immediate risk posed by the vulnerabilities they address. However, this rapid deployment must be balanced with strategies to minimize associated risks.

One effective strategy is clustering business-critical applications and applying rolling updates. In a clustered environment, updates can be applied to just the active node, allowing it to run and validate the update’s stability. Only after the update has proven stable should the update be applied to the backup node. This staggered approach ensures that there is always a functional node available, significantly reducing the risk of total system downtime.

Collaboration with SaaS Providers

The recent outage also highlights the crucial role that SaaS providers play in patch management. Companies like Palo Alto Networks and CrowdStrike, whose services are integral to their customers’ security postures, must collaborate closely with their clients to ensure updates are managed effectively. This collaboration should include clear communication about the nature and importance of updates, as well as providing tools and guidance to facilitate smooth deployment.

For instance, Palo Alto Networks recently faced an issue with a firewall bug that caused widespread disruptions. Such incidents underscore the need for robust patch management practices and proactive communication between SaaS providers and their customers. By working together, they can develop strategies to deploy updates with minimal impact on operations, such as phased rollouts and extended support for older versions during critical periods.

Conclusion

The recent Microsoft outage serves as a poignant reminder of the importance of effective patch management. By testing updates in pre-production environments, fast-tracking security updates with caution, and fostering collaboration between SaaS providers and their customers, organizations can mitigate the risks associated with software updates. These best practices not only enhance system reliability but also ensure that business operations remain uninterrupted, safeguarding the trust and satisfaction of clients and stakeholders.

Effective patch management is not just a technical necessity; it is a critical component of maintaining business resilience in an increasingly digital world.

The Importance of Patch Management to Avoid Downtime