A Hetzner Cloud snapshot can seed a replacement server, but it is only a copy of the source server’s disk at a point in time. It does not include attached Volumes, and it does not by itself transfer a live YouTube event or guarantee a seamless handoff.
Treat migration as a staged change: inventory the current setup, choose a consistency method, create a compatible replacement, restore anything outside the snapshot, and test the broadcast before cutover. Keep the original system available until you have verified the new one and know how you will roll back.
Understand what the snapshot does and does not contain
A snapshot records the server disk’s state when the image is created. You can use that image to create a replacement Cloud server, including in another location, but changes made on the source after the snapshot are not present in the image. It is a starting point for a new machine, not a live replica that stays synchronised with the old one.
The most important boundary is storage. Attached Hetzner Volumes are separate from the server disk and are not included in the snapshot. If your media, playlists, encoder configuration, logs, or other persistent files live on a Volume, the replacement will not receive them just because it was created from the snapshot. Hetzner’s snapshot documentation describes the snapshot scope and use; check the current documentation as you plan, because provider interfaces and procedures can change.
A snapshot may preserve installed software and configuration on the source disk, but do not assume that every service will boot and behave identically on a new machine. Network addresses, attached storage, firewall rules, system services, and application-level state all need separate validation. A cloned operating system can also retain old assumptions about device names, mount points, or network configuration.
Start with an inventory rather than the snapshot button. Record the source server’s architecture, type, location, public and private networking, firewall rules, attached Volumes, mount points, streaming process, and how the encoder receives its settings. Keep credentials out of the inventory document or store them in a proper secret manager; the stream key should not be pasted into a general-purpose migration note.
If your workflow is built around a particular encoder or loop process, document the command, service unit, working directory, and restart behaviour. Our guide to software for streaming pre-recorded videos to YouTube Live can help you identify which parts of the playback workflow must be recreated rather than inferred from the disk image.
Choose consistency over convenience when you can
Hetzner recommends powering off the source server before creating a snapshot to improve disk consistency. A snapshot can be made while the server is running, but Hetzner does not guarantee consistency for that case. This matters when the system is writing files, updating playlists, rotating logs, or changing application state while the image is captured.
A powered-off snapshot has a clear trade-off: the server is not broadcasting during the stop and snapshot window. If the stream cannot tolerate that interruption, you may choose to take a running snapshot, but make the uncertainty explicit. The image could capture data at different stages of application writes, and a file system image is not the same thing as an application-aware backup.
A practical sequence, when a short interruption is acceptable, is to announce or schedule a maintenance window, stop the stream process cleanly, stop the server, create the snapshot, and start the source again if it is still the production system. Keep the stop duration bounded by preparation: know which snapshot action you will use, where the replacement will live, and who will verify the source after it returns.
If stopping the source is unacceptable, see whether your software supports quiescing writes or whether its changing state can be backed up separately. You can also make independent copies of essential configuration and media. These measures reduce dependence on one snapshot, but they do not convert a running-server snapshot into a guaranteed consistent image.
Decide in advance whether you are accepting a possible interruption or a less certain image. There is no universal downtime figure: the time depends on the workload and the actions you choose. For a devotional or lofi loop that can restart from a known point, planned downtime may be simpler than an unverified live copy. For a time-sensitive channel, a separate playback and failover design may matter more than the snapshot itself.
Handle attached Volumes as a separate migration
Make a Volume list before creating the replacement. For each one, record its purpose, size, file system, mount point, and whether the stream process expects a particular path. Note which files are durable content and which are temporary data that can be regenerated. The snapshot will not bring these contents along.
Plan how the replacement will receive the data. Depending on your setup, you may attach an existing Volume to the new server where the service permits it, create a separate destination and copy data, or restore from another backup. Check the current Hetzner procedure for the option you intend to use. Do not attach or mount the same writable file system to two active systems unless your storage design explicitly supports that; otherwise, concurrent writes can corrupt or diverge the data.
After attaching or restoring, verify the file system and mount before starting the encoder. A service may start successfully while its expected media directory is actually an empty mount point on the root disk. Check that the expected files exist, that the account running the stream can read them, and that the directory has the expected free space for the workload.
Also inspect startup ordering. If the playback service starts before the Volume is mounted, it may fail or begin with incomplete content. Ensure the service depends on the mount, or use an explicit pre-start check that refuses to broadcast when the media path is unavailable. This is safer than allowing an empty playlist or fallback file to go live unnoticed.
Keep the old data intact until the new copy has been checked. If the source and replacement will both be running during tests, decide which one is permitted to write to each storage location. A clean read-only validation or a separately copied test dataset avoids ambiguity about which copy contains the latest playlist or recording.
Build a compatible replacement server
Create a new server from the snapshot rather than assuming you can move the existing server in place. Hetzner’s documentation says the snapshot and replacement must use a compatible CPU architecture. Verify the architecture before creation; do not select a replacement based only on a familiar server name or a similar-looking size.
Choose the target location and server type based on the actual workload. The image can be used in another location, but that does not move the old server itself. Consider CPU needs for decoding, scaling, or transcoding; memory for the operating system and encoder; and storage for the operating system, caches, logs, and any local recordings. A simple file loop may have different requirements from a pipeline that transcodes several sources.
Create the replacement as a staging machine first. Keep its public exposure limited while you inspect the operating system and services. Confirm administrative access, package and service status, system time, and the expected application files. Review any network configuration that refers to old addresses or interface names before making the host a production endpoint.
A snapshot-based clone can preserve host-level configuration that is no longer appropriate for the target. Check hostnames, monitoring identifiers, scheduled jobs, SSH access, and any scripts that might start the broadcast automatically. If both machines could start the same feed, disable the automatic stream service on the staging host until you deliberately begin a controlled test.
If you are currently using a VPS playback process that needs to recover after a crash, our guide to restarting a YouTube stream automatically on an OVHcloud VPS offers useful questions to ask of your own service setup: what is monitored, what is restarted, and what is logged. Its provider-specific steps do not replace testing on Hetzner, but the operational checks apply to a migration.
Restore networking and confirm storage paths
The replacement’s network is not simply a copy of the old server’s route. Recheck firewall policy, inbound administration access, any private network membership, and the outbound path to YouTube. Apply only the access rules the new machine needs. If your broadcast management interface is reachable publicly, restrict it as appropriate rather than inheriting a broad rule without review.
If your architecture uses a DNS name, proxy, private address, or external controller, document what actually needs to change at cutover. Some streams connect directly from the encoder host to YouTube and do not depend on an inbound web endpoint at all. Avoid changing DNS or other shared routing until the replacement has passed its private checks.
Test outbound reachability from the replacement rather than assuming that because the source worked, the target route will be suitable. YouTube’s streaming guidance recommends bandwidth headroom of 20% beyond the total bitrate of primary and backup streams. Treat that as YouTube’s recommendation, not a guarantee that a given route is stable. Measure the actual path under relevant conditions and account for other traffic sharing the connection.
Recreate mounts and verify permissions before enabling any stream process. If the encoder reads a file from a mounted directory, confirm the exact path as the service account sees it. Check the process logs for permission errors, missing media, or attempts to write recordings to a full disk. Do a restart test after the mount is in place so you know it persists across a reboot.
For channels with constrained uplink, bitrate choices and available headroom can determine whether a move improves or worsens stability. The practical checks in our low-upload-speed lofi streaming guide are relevant here: compare the encoder’s total traffic with the target host’s real outbound capacity, rather than relying on the old server’s experience.
Recheck the YouTube encoder and protect the key
The replacement needs the correct YouTube stream URL and stream key. A snapshot may retain an encoder configuration file, but treat that as a clue, not proof that the new process is using the intended event or current key. YouTube’s encoder setup instructions explain how to connect an encoder; follow the current instructions in Live Control Room for the channel and event you are actually using.
Keep the key private. Do not place it in a public script repository, paste it into a support post, or include it in logs that are shared outside your team. If you need to replace or rotate a key, do so through the appropriate YouTube controls and update the replacement encoder deliberately. A key copied from an old configuration could be stale, associated with another workflow, or exposed more widely than intended.
Check the encoder’s video and audio settings against the source material and the target stream. Confirm resolution, frame rate, codec, audio sample rate, bitrate, and keyframe behaviour in the actual encoder UI or configuration. Do not change several settings at once during cutover; retain a known working profile where possible, then adjust only when a test shows a specific issue.
If you use FFmpeg or another service-managed process, verify the command and environment on the new host. Environment variables may not be loaded by a system service in the same way they are in an interactive shell. Confirm that the process starts under the intended account, reads the intended source file, reconnects according to your own policy, and emits useful logs without disclosing secrets.
Plan how to avoid two encoders unintentionally publishing to the same event at the same time. Before a public test, decide whether the source or replacement owns the feed, and disable the other process accordingly. YouTube’s documentation explains encoder connection, but it does not promise that a host migration will preserve one uninterrupted event or that every reconnection will be seamless.
Test the stream and local recording before cutover
Boot and service checks are not enough. Start a controlled test using an unlisted or otherwise appropriate test event where available, and inspect the Live Control Room preview before directing viewers to the replacement. Verify that video and audio are present, the framing and levels are sensible, and the stream health indicators do not show a problem. Then check the watch page from a separate device or network.
Test the parts that fail quietly: audio that has stopped while video continues, a loop that reaches its end and does not restart, a missing media mount, and a service that exits without being restarted. If you use a primary and backup encoder, test failover by stopping the primary or disconnecting its network path in a controlled way. YouTube recommends testing encoder failover; its live streaming tips are a useful current reference for monitoring and preparation.
Record locally during the test and confirm that the file grows and can be played back. YouTube says a live stream longer than 12 hours may not be captured as an archive, so a continuous 24/7 channel needs an independent recording plan if retaining the programme matters. YouTube also notes that DVR availability on long streams can be limited; do not treat the watch page as your only copy of the content.
Check available disk space and the recording rotation or retention process. A local recording that fills the system disk can stop the encoder or prevent other services from writing logs. Keep recordings on the intended storage, set a workable retention policy, and confirm that a rotated file is usable before relying on rotation in production.
Do not let a successful preview stand in for a full operating test. Observe the stream long enough to see a loop transition, a recording file advance, and the monitoring or restart mechanism respond as designed. The time needed depends on your content and process; the point is to test the failure modes you have identified, not to claim that a fixed test duration proves long-term reliability.
Cut over deliberately and preserve rollback
Write the cutover sequence down in order. For example: confirm the replacement is ready, stop the source encoder, start the replacement encoder with the intended event and key, check the preview and watch page, verify recording and health, then update any endpoint or public notice that depends on the change. If there is no DNS or inbound endpoint to move, do not invent one; the change may simply be which host runs the encoder.
Choose one machine to own the production feed. Starting both in parallel can lead to duplicate or conflicting feeds, and keeping both writable against the same data can create a separate storage problem. Make the old process’s status explicit: stopped, disabled from automatic restart, or reserved for a defined rollback action.
Keep the old server and its data available until the new host has passed your checks. Define what would trigger rollback, such as a failed preview, missing media, repeated encoder disconnects, or an unusable local recording. Also define how rollback works: stop the replacement first, restore the source’s ability to run, and confirm which copy of any changed files is authoritative.
A snapshot is useful for reproducing a disk state, but it is not a substitute for a current backup of changing content or a continuity plan. Keep separate copies of irreplaceable media and configuration. If uninterrupted public viewing matters, test the intended event and encoder handoff before promising it to viewers; the snapshot alone cannot establish how YouTube will treat a break or reconnection.
For some channels, moving a server is more operational burden than the stream needs. If your main requirement is to keep a pre-recorded programme running while your own computer is off, StreamNeo removes the need to keep a separate server and encoder process under your own care by running the uploaded video as a YouTube live stream; it does not migrate or take over an existing Hetzner setup automatically.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does a Hetzner snapshot include attached Volumes?
No. The snapshot covers the server disk and does not include attached Volumes. Plan separately to attach, copy, or restore Volume data, then verify mounts and permissions before starting the stream.
Can I take the snapshot while the server is live?
Hetzner allows a snapshot of a running server, but does not guarantee consistency in that case. Hetzner recommends powering off the source to improve consistency, so choose knowingly between a controlled interruption and a less certain disk image.
Will the YouTube stream continue without interruption after migration?
A snapshot does not transfer an active YouTube event or guarantee seamless reconnection. Test the encoder and event workflow, inspect the preview and watch page, and keep rollback available before you announce the replacement as production-ready.
Do I need a local recording for a 24/7 stream?
It is sensible if you need a dependable copy of the programme. YouTube says streams longer than 12 hours may not be captured as an archive, so arrange local recording and check that files grow and remain playable.