Instead of requiring the user to manually backup the config files via a button, just save the files automatically, every 5 minutes, along with the other system metrics.

Why do we want to backup the node red configuration, considering that normally it is built from the version in github? It seems superfluous and a waste of space.

Instead of requiring the user to manually backup the config files via a button, just save the files automatically, every 5 minutes, along with the other system metrics.

Automatic backup is fine, just ensure you can select previous versions on the restore operation (will need to demonstrate that client-side attributes have versioning)--this will ensure if a erroneous backup is saved that a good backup can be restored. These will also be slow-changing dimensions, so make it once a day at most, but once a week is probably enough.

Why do we want to backup the node red configuration, considering that normally it is built from the version in github? It seems superfluous and a waste of space.

Backup the config.yml that is part of #27. Though, you do bring up a good point. The settings.js can have customization from a user, so it might also be useful to backup.

Regarding previous versions:

• How do you propose to identify previous versions? As far as I know, the Frigate configuration does not have a version identifier. I think the only option is to identify them by file date & time...? Although if we have the user trigger backups manually (rather than every N minutes), we can require the user to provide an identifier for each backup.
• How will users know what versions are available? Does the TM UI need to have a way to list the available versions?
• Just listing the versions by date and time may not be sufficient since that says nothing about the contents of each version.

As an alternative to backing up on a timer, we might be able to detect when a file changes and automatically trigger the backups.

Regarding backing up the config.yml that you are creating: That needs to wait until #27 is completed. Getting the infrastructure built for backing up the Frigate config will be a good start on that.

I am thinking about how the backups should be stored at the TB server. Options:

• As attributes. I think this is the easiest choice, but I am not sure about accessing previous versions.
• As telemetry. Ditto.
• In a database. I will have to investigate whether this is possible.

Assumption: given that we will be backing up multiple configuration files (Frigate, traffic monitor, maybe settings.js), I propose that we always backup/restore them jointly. We will not let the user restore just one file type because that just gets too complex and probably confusing.

Regarding previous versions

These are all initial work that we didn't originally scope for. It would be cool, but I would call it stretch or out of scope. We had this story limited it to a backup/restore button so we didn't have to version and address this. Though, I do like the idea of addressing content of the backups (maybe just with a download before restoring--make it a double-click to restore).

As an alternative to backing up on a timer, we might be able to detect when a file changes and automatically trigger the backups.

The big thing is we don't want to [automatically] overwrite a backup file without something to fall back to. Trigger it on a button so it is intentional. We can link to automatic triggers, but if a user is just "trying something", they will WANT a server backup to fall back to if something completely crashes the system. So, I would say avoid automatic backup on every file change.

I am thinking about how the backups should be stored at the TB server.

The OP story specified client-side attributes. Stick with that. Telemetry would, by nature of being time-series data have timestamps and "versions", but we are not particularly interested in history for configuration. And then we'd have to do the work in the first 3 bullets you mentioned. I could be persuaded to shared attributes, but I don't think we want the server making changes to backups. For changes, we should probably implement some other push system.

Assumption
Agree that all backup files get backed up and restored at the same time. The main point of this story is to get back to an operational state from corruption, failure, or factory reset.