Save backup files to a dedicated directory?

General Discussion
1

I opened a PR that saves the klipper backup files in a dedicated backups directory (inside the config directory).

@koconnor suggested that I should gather some feedback from the community, so let me know what your thoughts are.

PR: configfile: Save backup files to own directory by abmantis · Pull Request #5643 · Klipper3d/klipper · GitHub

1 Like
2

Two points i think might be worth considering, are the following.

  1. allowing users to specify the backup folder, would allow users some additional convenience/flexibility if they are syncing backups to an external device, or their config from an external devise.

  2. allowing the user to specify that the entire conf folder should be back up might work better for some users, as a lot of users are no using includes to make their config modular.

3

My personal opinion:

  • The backups are good to have in case you screwed your config
  • In all my Klipper career I had to use them once or twice
  • If you specified an own cfg folder, e.g. to have monnraker, klipper etc configs in one place, the backups really do not bother me at all

→ I personally do not need this and every line of code means source of bugs / incompatibilities with new Python versions / maintenance effort

Of course others with different workflows might have a different view on it.

4

I agree that allowing to specify where the backups go would be better, but I’m not even sure where that configuration would go. Suggestions?

5

I think this is critical, and am surprised it doesn’t already exist.
Following the pattern of many other software projects, there should simply be a parameter that’s part of the configuration for the module that’s actually dong the work of backing up the configs (e.g. Moonraker, Mainsail etc)
backup_path: ~/my_backups/
or a relative path within ~/printer_data/configs/ e.g.
backup_path: backups/

What’s doing the actual backup? A macro?

6

I think it is completely uncritical and that there is no need to implement this natively in Klipper:

  • On the typical SBCs that are used with Klipper there is no such thing like a backup location (all is on the same SD / eMMC)
  • Regular backups of the printer.cfg are already created
  • If this SD / eMMC should die, then also your backup is gone
  • If you have the knowledge to set up and map remote drives like samba / NFS then it should be easy to do a regular backup via tools like rsync or rclone and cron
  • You could even use git and github to “cron-away” your config how often you would like

With a full Linux system at your command, there are basically endless possibilities how you could create your individual backup strategy. There are also an abundance of guides available how to do this.

Doing backups on a failure prone SD card absolutely makes no sense and implementing any other form of remote backup adds a lot of complexity that is not Klipper’s core business.

7

Just for the fun of it:

This script will monitor given folders (settings on top of the script) and whenever something changes in these folders, a backup is created.

Backups can be either created locally at a given path or on a remote drive with the help of rclone (which needs to be configured first before it can be used in the script)

Requires:

  • apt install inotify-tools rclone

Run with:

  • ./backup_klipper.sh local & → Only local backups
  • ./backup_klipper.sh remote & → Backup to the configured remote
  • If you want to get fancy, you can start it via a systemd unit

Only loosely tested and only intended to demonstrate one of many possibilities

1 Like
8

I couldn’t agree more that backups are NOT the responsibility of Klipper, especially as you correctly point out, on an embedded system with limited resources. That’s why I’m surprised to see that there IS ALREADY a config backup system, notably without a way to configure its behavior. This is what I’m pointing at.
For example, one desirable option may be to turn OFF the config backup, for example because the configs are already in source control.

Your scripts/examples may help out *nix noob who can’t already do sysadmin task in their sleep. iNotify doesn’t require timers, so that’s what I’d use if there’s not a native way to do it: e.g. ON–>OFF

Where in the Mainsail/Moonraker/Klipper stack is this config save actually occurring? I’m a Klipper noob.

9

There are some things to consider and understand when discussing a backup strategy:

Klipper ecosystem

  • “Klipper” consists of different software products that are developed by different people
  • Klipper Architecture / Ecosystem gives you an idea about it
  • Depending on what you installed and how you installed it, there might be different files in different locations that could be worth backing up
  • This can even include files in, e.g. /etc/nginx/ (although typical users will only seldom customize this) or the Moonraker lmdb database or even again 3rd party databases like spoolman

“Core Klipper” backups

  • Klipper itself is creating “backups” of the printer.cfg file
  • This is not really a backup (because of the limitation discussed in my posts above) but a very light “version control”, i.e. allowing you to return to a previous printer.cfg in case you messed it up
  • External cfg that are included via [include bla.cfg] are not subject to this “backup”
  • As such, it does not make a practical difference where they are, and an option to customize this path does not really change the game in any way.

Having the above in mind, a proper backup strategy is somewhat complex and highly depending on the individual setup and personal preferences.

Personally, I only keep backups of my cfgs and do not care for the rest, since I do not mind loosing my Moonraker stored print history or any customization done in the web-UIs.
And since I do not modify the cfgs like 20 times a day, I’m also quite relaxed about this topic.

Again, your personal preferences and workflows may vary, so I’d consider a proper backup strategy to be the individual users’ responsibility (as it is the case in virtually every software product I know).

Edit:
Just to be on the same page: In my definition, a “backup” is a copy of a file or data that is NOT stored on the same system and / or medium as the original file. This is even more true on systems running on a SD card.
Everything else is just a “nice to have” in the best case and in no way a protection against loss or disaster.

1 Like
10

Yes, I agree with that.