To upload a video from your computer to a Linux VPS, use rsync over SSH and send it to a dedicated directory that your VPS account can write to. If the connection breaks, rerun the same command with a private partial directory; do not treat append mode as the general way to resume a finished video.
The important distinction is between an incomplete transfer of a file that is already finished and a source file that is actively growing. Rsync’s partial-directory options are the ordinary recovery path for the first case. Append options are specialised tools for the second, when you know the existing remote bytes match the beginning of the source.
Check rsync on both machines
A remote-shell rsync transfer needs rsync available at both ends: on the machine sending the video and on the VPS receiving it. SSH carries the connection, but it does not replace the remote rsync program. If one endpoint lacks rsync, the transfer will fail before it can copy the file.
Check the local machine first by running rsync --version in a terminal. Then connect to the VPS and run the same command there. The output should identify rsync and its version. If the command is not found, install the package using the instructions for the operating system on that particular machine, then check again. Package names and installation commands vary, so avoid copying a command intended for a different distribution.
Version matters when relying on a particular optimisation. The rsync manual notes that in-place reuse of a file in a partial directory requires rsync 3.2.0 or newer at both ends. The basic workflow remains useful without assuming that version-specific behaviour, but efficiency and reuse details may differ. If you administer both machines, record the versions before deciding what recovery behaviour to expect.
The syntax used below has one colon between the host and the remote path, as in [email protected]:/srv/videos/. That form selects a remote-shell transfer; SSH is a supported remote shell. Do not confuse it with a double-colon rsync daemon address, which is a different transport arrangement. The rsync manual documents remote-shell syntax, endpoint requirements and the options used here.
Choose a dedicated writable media directory
Choose the final destination before sending a large file. A directory such as /srv/videos/ is easier to understand than an ambiguous home directory or a system path. The exact location is your choice; what matters is that it is intentional, has enough available space for the video and is writable by the VPS account used in the command.
Check access while logged in as that account. You can inspect the directory with ls -ld /srv/videos and, if it exists, try creating and removing a small temporary file there. If the directory does not exist or the account cannot write to it, ask the VPS administrator or use the appropriate account permissions to prepare it. Do not solve a permissions problem by making a broad system directory writable to everyone.
Keep staging data apart from the finished media. With --partial-dir=.rsync-partial, rsync stores incomplete data in a separate, relative directory alongside the destination. That directory is not the video library: a player, playlist process or streaming tool should not treat its contents as finished videos. The rsync manual also warns that the partial directory must not be writable by other users. Use an account-private destination and limit access accordingly.
This separation is useful when a VPS is already serving a continuous channel. If a playlist scanner sees a half-uploaded video under its normal media path, it may attempt to read a file that is not complete. Keep the incomplete copy out of the folder your playback process watches, then verify the final file before moving it into the active library if your workflow requires that separation. For an example of the later playback side, see the guide to running a 24/7 Kannada devotional channel with VLC.
Connect to the VPS over SSH
Before starting rsync, make sure you can sign in to the VPS with SSH using the same username and host you plan to put in the rsync destination. A basic connection looks like ssh [email protected]. Replace the example username and hostname with the actual values supplied for your server. If your provider uses a non-default SSH configuration, use the connection details it gave you rather than assuming the examples apply unchanged.
A successful SSH login confirms that the host is reachable and that the account is recognised. It does not by itself confirm that /srv/videos/ exists or is writable, so check that separately. If SSH cannot connect, resolve that first; rsync cannot use the remote-shell transport until SSH works. The OpenBSD SSH manual is a primary reference for the SSH client, but your VPS provider’s access instructions should determine your host, account and any required configuration.
Use the host name consistently. A different alias, account or remote path can lead to a transfer landing somewhere other than the directory you checked. Before a first full upload, an optional low-risk check is to send a small test file to the same destination and confirm where it appears. This is particularly helpful if you have multiple VPS accounts or a channel setup with separate staging and playback folders.
Upload a video with rsync
From the local machine, run a command like this, substituting the local filename, account, host and remote directory:
rsync -av --info=progress2 --partial-dir=.rsync-partial -e ssh -- ./video.mp4 [email protected]:/srv/videos/
The source is ./video.mp4; the destination is the remote account and directory. The single colon after the host denotes remote-shell transport. -e ssh specifies SSH for that connection, -a selects archive behaviour, and -v asks rsync to be more informative. --info=progress2 displays transfer progress. The -- separates options from path names, which is useful if a filename begins with a dash. The relative .rsync-partial location keeps interrupted data separate from the final filename.
The example assumes you have already confirmed that the remote directory exists and is writable. It also assumes the local file is complete and is not being edited while rsync reads it. If the source changes during transfer, you need to establish which version is meant to be uploaded before relying on the result. For a fixed video export, leave the file unchanged until the transfer and any verification are complete.
For a folder of videos, do not simply add a wildcard and assume the result will have the intended layout. Rsync’s trailing-slash behaviour affects whether the directory itself or its contents are placed at the destination. Consult the examples in the rsync manual and test the exact source and destination paths with a small sample before syncing a library. A single-file command is easier to reason about and less likely to put a folder one level too deep.
Video files are already encoded for playback, so compression with -z should not be a default assumption. It may add processing without producing a useful reduction for a particular file and connection. If you want to evaluate compression, make it a measured choice for your own material rather than expecting it to make every video upload faster.
A completed command is a useful indication that rsync finished its work, but it does not excuse checking the destination when the video matters to a live schedule. A local source that is removed early, a mistaken path or an account permission issue can turn a seemingly routine transfer into an avoidable problem. Keep the original until you have confirmed the remote copy.
Resume an interrupted transfer safely
If the connection drops, or the terminal closes before the command finishes, first check whether rsync is still running and whether SSH is still connected. If the process has ended, rerun the same command with the same source path, remote account, host, destination and partial-directory setting. Rsync can use preserved partial data to speed a subsequent transfer where applicable. It will compare the source and destination state rather than requiring you to invent a different command for recovery.
The partial directory is valuable because an incomplete transfer is not published under the final video filename. That reduces the chance that a playback tool will open it as though it were ready. Do not rename a partial file into place, delete the staging directory before retrying, or point a streaming playlist at it. Let rsync manage the staging data and complete the transfer; then verify the result before using it.
This is not a promise that every interrupted transfer resumes from precisely the last byte or that every saved temporary file will be reusable. The outcome can depend on rsync versions, the state left at the destination, changes to the source and the options used. In particular, the manual describes modern in-place reuse of partial-directory data as requiring version 3.2.0 or later on both machines. Rerunning the command is the safe, repeatable next step, but check its result rather than assuming the file is complete.
The short option -P is often encountered in examples. It combines --partial and --progress; it does not specify a separate partial directory. For a media destination where you want incomplete data separated from the final filename, the explicit --partial-dir=.rsync-partial choice makes that staging decision visible. Do not add flags you do not understand simply because they appear in a generic command copied from a forum.
If a long transfer is interrupted repeatedly, preserve the source file and repeat the same command after confirming connectivity and destination access. A restart can still take time, and no command can compensate for insufficient disk space or a changing source. If the VPS is also responsible for an always-on broadcast, keep the upload and playback steps distinct: the transfer prepares a file, while the playback system determines when it enters the programme. See the practical guide to scheduling different video playlists on a YouTube livestream for the scheduling side.
Use append modes only for verified growing files
--append and --append-verify are not general-purpose resume switches for a finished video. Their assumption is specific: the file already on the receiving side is a byte-for-byte prefix of the source, and that source is still growing. That can be relevant to a file being written continuously, but it is not the normal situation when uploading a completed MP4 that was interrupted halfway through.
If the remote file is not known to match the start of the source, append can produce an incorrect result. Similar filenames are not evidence of matching bytes. A prior failed upload, a replaced export or a file with the same name from another edit does not establish the prefix condition. For an ordinary finished video, use the partial-directory workflow and rerun the transfer instead.
--append-verify adds verification of file data, which is a more cautious choice under the same growing-file assumption but involves additional work. It does not remove the need to know that the receiver’s existing bytes belong to the source being appended. Choose it only when that condition is established and the workflow genuinely involves a growing file. Consult the rsync manual’s descriptions of append options before using them in a production process.
| Approach | Appropriate case | Main trade-off |
|---|---|---|
--partial-dir=.rsync-partial |
A normal file transfer may be interrupted, and incomplete data should stay separate from the finished filename. | Requires a private staging directory; exact reuse behaviour can depend on rsync versions and transfer state. |
--append |
The receiver’s file is known to be an exact prefix of a source that is still growing. | Relies on that prefix assumption and is unsuitable as generic recovery for an arbitrary interrupted video. |
--append-verify |
The same verified growing-file case, with verification of file data desired. | Adds verification work and still depends on the growing-file assumptions. |
Avoid casually adding --inplace to an ordinary video transfer. Rsync warns that an interrupted update using in-place changes can leave the destination inconsistent, and that other users should not access a file while it is being updated. A separate partial directory and a final file that becomes available only after completion are easier to manage for a channel library.
Verify the transferred file on the VPS
After rsync reports completion, inspect the destination from the VPS account. Confirm that the expected filename is present in the intended directory and that it is not sitting inside .rsync-partial. Check that the file has a plausible size and that the account or playback process that needs it can read it. A path check matters as much as a transfer check: a complete file in the wrong directory is not ready for your channel workflow.
If you need an independent integrity check, calculate a cryptographic checksum for the local file and the remote file, then compare the values. Use a checksum utility available on both systems and check its documentation for the exact command appropriate to those operating systems. Matching checksums provide stronger evidence that the files contain the same data than comparing names or apparent sizes alone. This step is optional for routine transfers but sensible when a particular upload must be confirmed independently.
Do not make an incomplete or unverified file the active version while your playlist or broadcast process may read it. Once the file is confirmed, move or copy it into the directory your playback setup expects, if that is separate from the upload destination. For a channel that loops material continuously, the upload is only one part of the workflow: the video still needs to be prepared, scheduled and selected by the playback system. The guide to streaming a 24/7 kirtan channel with a cloud relay covers a different part of that broader operating picture.
When a failed transfer leaves a partial directory behind, do not treat its existence as proof that the final file is usable. Rerun the command, wait for it to finish, then inspect the final destination. If you no longer intend to continue that upload, remove only the abandoned staging data after checking its location and confirming no rsync process is using it. This avoids deleting the final media accidentally while cleaning up a similarly named path.
If your actual goal is not to manage a VPS and its files, but to keep an uploaded video broadcasting without leaving your computer running, that is a different operating choice. StreamNeo removes the need to keep a local machine on for that specific continuous-playback task after the file and YouTube channel are prepared; it does not change the need to verify a file before using it.
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
Rsync long job failed, can I reuse tmp files?
Rerun the same rsync command with the same paths and the same partial-directory setting. Rsync may use preserved partial data to help continue, but you should wait for the command to finish and verify the resulting file rather than assuming the temporary data guarantees recovery.
Is -P enough to keep an interrupted video separate?
-P is shorthand for --partial --progress, so it does not name a separate staging directory. If you want incomplete data kept away from the final filename, specify --partial-dir=.rsync-partial and ensure that directory is private to the account performing the transfer.
Can I use --append-verify for any interrupted MP4?
No. It is intended for a receiver file that is known to be an exact prefix of a source that is still growing. For an ordinary finished MP4 interrupted during upload, rerun the partial-directory command instead.
How do I know the VPS copy is complete?
Check that rsync finished successfully, then inspect the expected final path and file. If you need an independent check, compare a cryptographic checksum generated on each machine using a utility available on both systems.