What actually needs backing up on a Creality K2 (and why I built a tool for it)

The K2's filesystem is busy. There's an OpenWrt root, a /usr/share/ tree owned by Creality's update package, a /mnt/UDISK/ user partition, log directories, camera recordings, slicer-uploaded gcode, web assets, and a handful of bind-mounted Moonraker bits. If you're trying to figure out what to back up before a firmware update, a hardware swap, or a config experiment, "everything" is impractical and "just printer.cfg" is wrong.

This is what's actually worth saving, what isn't, and why I ended up writing a one-click tool for it.

What the printer keeps where

The paths worth knowing on a stock K2:

• /mnt/UDISK/printer_data/config/ — your printer.cfg, included macro files, slicer profiles, mesh data, SAVE_CONFIG bake-in. Critical.
• /mnt/UDISK/printer_data/database/ — Moonraker's job history, print stats, settings. High priority.
• /mnt/UDISK/printer_data/logs/ — klippy.log, moonraker.log. Useful for diagnosis only.
• /usr/share/klipper/klippy/extras/ — Klipper Python source. Vanilla unless you've patched it; skip unless patched.
• /usr/share/moonraker/components/ — Moonraker Python source. Same story — skip unless patched.
• /usr/share/moonraker/moonraker.conf — Moonraker config. Creality hides it here, not in printer_data/config/. Critical.
• /mnt/UDISK/printer_data/gcodes/ — uploaded slicer files. Optional, can be large.
• /mnt/UDISK/creality/userdata/ — touchscreen state, network, device-specific overlays. High priority.

The non-obvious one is moonraker.conf. Creality moved it out of the standard printer_data/config/ location to discourage users editing it from the web UI — it contains camera and cloud-integration settings they don't want broken. It still gets read on every Moonraker start, so if you don't back it up and your overlay file gets nuked, you'll lose your authorisation, CORS, webcam, and update-manager configuration in one go.

What's not worth backing up

A few paths that look important but aren't:

• Anything in /tmp/ — it's tmpfs, gone on every reboot. Includes the live klippy.log while running.
• /var/log/ outside of printer_data/logs/ — system logs that regenerate.
• Camera recordings — they're enormous and have nothing to do with restoring print capability.
• The Klipper firmware binary — it's compiled from source on the controller's MCU; restoring it from backup risks version skew.
• /mnt/UDISK/system_update/ — the update staging directory. If you back it up and restore later, you'll re-trigger updates that have already been applied.

What changes between firmware updates

Creality firmware updates can touch any of: files under /usr/share/ (Klipper, Moonraker, web UI), the kernel and OpenWrt overlay, touchscreen application binaries, and the default printer.cfg template — your existing one is preserved, but the defaults a new printer would get can drift.

What an update should never touch: anything under /mnt/UDISK/printer_data/, moonraker.conf (in the hidden location), and your calibration data (mesh, PID, shaper).

In practice updates occasionally nuke the wrong thing. Custom Klipper patches under /usr/share/ are the most common casualty, which is why I keep a patches/ directory of one-shot scripts that re-apply them after any update.

The manual backup approach

If you want to do this without any tooling, SSH in. From your workstation:

ssh root@<k2-ip> 'tar -czf - /mnt/UDISK/printer_data/config/ /mnt/UDISK/printer_data/database/ /usr/share/moonraker/moonraker.conf /mnt/UDISK/creality/userdata/' > k2-backup.tar.gz

Default password is creality_2024. The resulting tarball is usually 5–50 MB depending on print history.

Restore is the reverse — extract the tarball back into /, restart Klipper and Moonraker, done. Any path that didn't exist gets created; existing files get overwritten.

Why I built K2 Backup

Three reasons the manual approach falls over for normal users.

First, most K2 owners aren't comfortable in SSH. Posting "open a terminal and paste this tar command" on a Reddit thread loses 80% of readers immediately.

Second, the right file list isn't obvious. People back up printer.cfg, miss moonraker.conf because it's in the weird location, and find out it mattered only after a restore.

Third, verification is critical. A backup that didn't actually capture anything is worse than no backup, because it gives false confidence. The tool should verify file sizes after pulling.

So I wrote K2 Backup — a small Windows app that asks for your printer's IP, connects over SSH, pulls the right list of files, verifies them, and writes a timestamped zip. It's free, it's 234 KB, it doesn't phone home, it doesn't need admin rights. Reddit's r/CrealityK2 and the Creality K2 Facebook group have been using it since launch.

If you'd rather do it manually, the tar command above is the same operation by hand. The tool just removes the four ways a manual backup goes wrong.

When to back up

A few rules I follow on my own machine:

• Before any firmware update. Always.
• Before any patch to /usr/share/ files. Always.
• Before SAVE_CONFIG cleanup or major macro edits. Always — see the companion piece on cleaning up a bloated SAVE_CONFIG section.
• After a successful calibration session. Yes — your hard-won shaper, mesh, and PID values are baked into printer.cfg's SAVE_CONFIG region, and if anything corrupts that file you'll be redoing the calibration.
• Once a month, automatically, if you can. Cron + scp from your home server is the lazy correct answer.

The shape of "good backups" for any Klipper printer is the same: capture printer_data/, capture the Moonraker config wherever it lives, capture any custom patches separately, ignore anything that's regenerated. The K2 just hides one of those locations more than usual.

K2 Backup is free to download — Windows only for now.