Manual uploads only protect you on the days you remember to do them. JKSV can upload backups automatically, so every new backup is copied to your cloud destination as part of the backup itself. This guide explains how automatic upload behaves, the ZIP requirement behind it, and the local-copy option you should keep enabled. You need a working cloud connection first, either Google Drive or WebDAV, and JKSV installed from the download page. See the cloud backup hub for the full series.
What auto-upload actually does
When automatic upload is enabled, completing a backup in JKSV also sends that backup to your configured cloud destination. The point is to remove the gap between making a backup and protecting it off the console: an SD card can fail, be lost or be corrupted by an unrelated crash, and a backup that only ever lived on that card fails with it. Auto-upload closes that gap at the moment the backup is created, with no extra menu steps to forget after a long play session.
Auto-upload works with both cloud paths JKSV supports, the native Google Drive integration and WebDAV servers, so the choice of provider stays yours. What changes is only the timing: uploads stop being a separate chore and become part of the backup itself.
Why cloud backups are always ZIP
JKSV stores cloud backups as ZIP archives, and this is not optional. A local backup can be an unpacked folder, which is convenient when you want to open the save in a PC editor, but a folder of many small files is a poor unit for network transfer and storage. A single ZIP is one file to upload, verify, download and keep intact, and it is the format JKSV requires for anything sent to Google Drive or a WebDAV destination. Expect your cloud copies to be ZIPs even when your SD copies are folders.
This split is actually useful. Keep local backups as folders when you edit saves, and let the cloud hold the sealed ZIP snapshot of the same moment. If an edit goes wrong, the ZIP is the untouched original you restore from.
Keep local backups enabled
JKSV offers an option to keep local backups alongside cloud uploads, and you should leave it on. The current release, tag 12/02/2025, specifically fixed a crash involving the interaction between Keep Local Backups and auto-backup behaviour, which underlines how central the combination is to normal use. A local copy restores instantly with no network, while the cloud copy survives the loss of the card or console. Together they cover the realistic failure cases; either one alone leaves a hole.
The strategy behind pairing copies is covered in depth in cloud vs local save backups, including the 3-2-1 principle. Treat auto-upload as one leg of that strategy, never as a reason to delete local copies to save a little SD space.
A sane routine to adopt
A practical routine looks like this: enable auto-upload, keep local backups on, and back up before anything risky, such as editing a save, moving to a new SD card, or updating your firmware or CFW. After a session in a game you care about, run a fresh backup and let it upload. Once a month, open your Drive or WebDAV folder on a PC and confirm recent ZIPs are present and open correctly. Verification takes minutes and is what separates a backup system from a backup ritual.
If you use pCloud as your WebDAV backend, the dedicated walkthrough is JKSV with pCloud over WebDAV. For other backends, the provider comparison weighs Koofr, self-hosted options and Google Drive.
Limits to keep in mind
Auto-upload still needs a working internet connection on the console at backup time; a backup made offline simply stays local until you upload it. Very large saves take time to send, so let the transfer finish before sleeping the console. And no upload setting protects a save you never backed up in the first place, so the habit of backing up before risky changes remains the foundation everything else builds on.
Set it up once, test it with a small title, verify the ZIP at the destination, and your future backups will quietly protect themselves.
