Can I import a Droplet snapshot into Hetzner?

DigitalOcean currently does not offer downloads of its backups and snapshots. This guide therefore uses a new destination server and an application-level data migration instead of snapshot import.

What is the purpose of a pre-migration snapshot?

It is an additional recovery point at DigitalOcean. It replaces neither transfer to Hetzner nor verification of consistent database restoration.

Can I transfer files with rsync?

Yes, for selected paths over SSH. Permissions, owners and any ACLs must suit the application. The example starts with a dry run and does not copy a whole machine.

Does rsync also copy Managed Databases and Spaces?

No. Synchronising a Droplet file path does not include independent managed services. Databases and Spaces need separate inventory, export and verification procedures.

Is a live snapshot enough for a consistent database?

Not universally. DigitalOcean notes consistency issues with running databases and recommends shutting down before snapshotting depending on the services. A database backup method still needs separate assessment.

Is migration possible without interruption?

This guide does not promise that. Its procedure uses an agreed write freeze for the final dataset. Other methods need a separate replication and consistency plan.

Must I transfer my domain as well?

The procedure separates application cutover from domain administration. Plan the necessary DNS changes and access; a registrar transfer is outside this guide.

What still needs checking after DNS cutover?

Login, permissions, uploads, writes, background jobs, external integrations, backup and monitoring. The return path must account for new destination data.

DigitalOcean Droplet to Hetzner: Migration with rsync

Timo Wevelsiep30.10.2026

#Cloud
#Migration
#Hetzner

Editorial note: The information in this article was compiled to the best of our knowledge at the time of publication. Technical details, prices, versions, licensing terms, and external content may change. Please verify the information provided independently, particularly before making business-critical or security-related decisions. This article does not replace individual professional, legal, or tax advice.

Scope the Droplet move: Migrate DigitalOcean to Hetzner. Arrange a consultation.

This guide rebuilds a Droplet as a new Linux application server at Hetzner. Files, database and a controlled cutover follow. The key difference from moving within DigitalOcean: backups and snapshots currently cannot be downloaded. A snapshot is therefore not a directly transferable import package here.

As of October 2026. The following steps are our recommendations for an administered Linux application with defined data paths. They are no promise of a particular migration duration.

Distinguish snapshots from data migration
Inventory the Droplet and external services
Prepare the destination and access
Transfer files with rsync
Transfer the database and final dataset
Plan cutover with acceptance and a return path
Our approach at WZ-IT
Further guides

Distinguish snapshots from data migration

A Droplet snapshot saves disk state at DigitalOcean. Depending on running services, the documentation recommends shutting down for consistency. A live snapshot is therefore not a universal guarantee of database consistency.

Our recommendation: retain an appropriate recovery point at the source and plan transfer separately. The new server must become operational from verifiable configurations and data. Transferring a full system image instead requires a separate procedure covering boot, drivers and networking; that is not the process described here.

Purpose	Planned means	Does not replace
Restore the source	Suitable backup at DigitalOcean	Migration to Hetzner
Transfer application files	Selected paths over SSH	Database backup
Transfer the database	Engine-specific export and restore	Role and application checks
Switch operations	Agreed runbook	Acceptance and return path

Inventory the Droplet and external services

Before provisioning, record which data lives inside the Droplet and which lives elsewhere. Our suggested inventory covers OS, architecture, runtimes, services, mountpoints, users, uploads, secrets, DNS, certificates and external interfaces.

Each persistent path needs answers to three questions: who writes to it, which state should be transferred and who verifies the result? An unclear data path is an unresolved cutover issue.

Explicitly assess additional volumes, Managed Databases, Spaces, load balancers and external services as separate inventory items. Transferring a local upload directory does not capture them. The Spaces to Hetzner guide describes a separate object storage path. This article covers server migration and does not replace an object storage transfer.

Also record jobs and incoming webhooks. We recommend inventorying secondary write paths together with web access. Otherwise it remains unclear who can still modify the final dataset during cutover.

Prepare the destination and access

We recommend a fresh destination installation with a deliberately chosen OS, architecture and application release. A price comparison alone is not a compatibility check. The DigitalOcean vs Hetzner comparison covers bundle pricing and operational scope separately.

Define runtime, packages, service accounts, persistent directories and restart procedures. Establish SSH access, sufficient storage and recovery before copying data. Limit access to the connections required.

The Hetzner data migration guide describes backup and transfer to a new server. Our procedure follows its distinction between data migration and moving an entire partition. We recommend deliberately transferring configurations rather than replacing the destination with a wholesale copy of the source filesystem.

Transfer files with rsync

The following example transfers only the contents of /srv/app/uploads/. Account, destination address and paths are placeholders for your environment. Start by inspecting the output:

rsync -av --dry-run -e ssh /srv/app/uploads/ migration@TARGET_IP:/srv/app/uploads/

Remove --dry-run only after checking direction and destination path. In the rsync manual, the option simulates the run; archive mode alone does not cover every metadata type. Plan necessary owners, ACLs and extended attributes against application requirements. The example deliberately includes neither deletion reconciliation nor a full system copy.

Our verification recommendation: compare files with the agreed reference, check permissions and read representative files through the application. Repeat reconciliation after the write freeze. A completed copy process alone does not establish business correctness.

For containers, separate reproducible deployment from persistent application data. Record every required data path in the inventory; a deployment manifest alone does not replace backed-up data in this process.

Transfer the database and final dataset

Choose a backup and restoration procedure appropriate to the database engine. For PostgreSQL, pg_dump is a consistent single-database dump; required roles and additional databases need separate consideration. For MySQL or other engines, define the relevant method separately.

We recommend a restoration rehearsal in the isolated destination first. Check not only import completion but also roles, permissions, extensions and business queries. Record the result in the migration log.

For the final state, this runbook uses an agreed write freeze. Stop the previously inventoried writing requests, jobs and imports. Then transfer the final database state and reconcile mutable files again. Enable destination writes only after the agreed checks.

If a write freeze is unacceptable for the application, plan a different transfer and replication method first. The rsync command shown here does not make this an interruption-free migration.

Plan cutover with acceptance and a return path

Our recommended acceptance checks the application under its intended hostname: login, roles, upload and download, writes, outbound email and external integrations. Also check restart, backup and monitoring according to the agreed operational scope.

DNS cutover and domain administration remain separate work items. Ensure the responsible people can change the necessary records. Also record when destination jobs will be enabled and source jobs disabled.

A return must also handle new destination data. Define abort criteria, the authoritative dataset and responsibility for transferring it. Changing DNS back without that decision is not a complete return path.

Decommission the source, snapshots and other resources only after acceptance and resolving retention. For costing, we recommend including data transfer, parallel operations, backup and support alongside destination resources. This does not imply that every Droplet migration saves money.

Our approach at WZ-IT

DigitalOcean to Hetzner migration is the destination offer for this guide. The Cloud Exit Check helps when target architecture and scope remain unresolved. Hetzner expertise adds the platform context.

A Droplet list, data paths, database type, data volume and external dependencies help scope an enquiry. Migration, acceptance and subsequent operational responsibilities are defined against that starting point.