OSMC Backups, default for # of files to keep set to 0 or at least 2?

Feature Requests
1

Any chance of having the default for the number of backup files to keep, set to 0(infinite), or at least 2? I understand 0 might cause you more support issues because of disc space, but the current default setting of 1, means I lost my older backup that had many files I needed. {sad panda}

My Vero bricked recently, so I restored my new device via my last full backup, which had all of my customizations, etc. Because I hadn’t had time to test my custom addons with Python 3, so I used an OSMC image from 2019. Recovery went well. I tested that all my custom addons worked with Python 3. I should have just done a distro upgrade, but I decided to re-wipe the device with the latest version. I setup auto backup on update (but forgetting about the 1 file default) and when I did the latest update it wiped out my old backup.

I was able to coble together most of what I needed, but a default setting of 2 would have helped me.

THANKS!

2

And what if your third backup had been the one with all your stuff in instead of the second? Would you be asking for 3 to be the default?

1 Like
3

I forget what the name of the math/statistic problem this represents is called, but it’s exponential(?) less likely to be 3/4/5/etc back, because the whole point is catching it right after an automated backup.

If you’ve gone on, and done another manual backup or waited until the next release for an auto-backup to be triggered before upgrading, that scenario of needing a older and older backup becomes less and less likely.

Make sense?

4

Sort of. So you need to retain a backup that works with a previous release. Here I make sure the last backup before a major upgrade of Kodi or Debian is parked safely away from my automated daily backup system. I think the last major upgrade was flagged clearly enough for users to take action.

5

Making a “default” detail for all users is a “bad move”, having it at 1 and let the concerned user change to their preference is a solution that works. I see your point, but you are “just you” and I know the argument that it’s better for all parties.

Then I beg of you to think of old grandma that isn’t aware of backup and just “inherited her grandsons old pi2 with a 4 gb sd-card”. She never enter settings, her son has given here instruction press manual backup before major upgrade or he comes to her place and do it every 6 months, how long do you think he’ll remember that it’s only a 4gb card? Well, here comes 3rd upgrade, it fails because she has no idea/he didn’t rember that a 4gb card wont hold a lot of backups.

7

You’re coming up on the five-year mark for vero4k. I had an early one, and it recently bricked (@sam_nazarko tried to help me restore, but the internal storage was most likely corrupted).

After I made that post, someone else posted having the exact same issue. In my mind that increases the likelihood that at least one batch of your early vero4k boxes had faulty storage chips. Depending on how large your batches are, you could be facing my exact use case, of getting a new box but using my old SD-Card.

The real evaluation should therefore be:

  1. Would a default of 2 “hurt” anyone: No, having two backups wouldn’t blow granny’s 4gb sd-card (can you even buy sd–cards that low anymore?)
  2. Does it increase our support load: No, again, having two backups wouldn’t blow granny’s 4gb sd-card, causing increased support requests
  3. Would a default of 2 “help” anyone: Yes [not gonna repeat my logic from above ]

Does the benefit of 3, provide more customer benefit than the “cost of 1 & 2”. I believe it does because I do not believe my use case to be strictly limited to “just [me]”.

I will add, that I did the restore via the freshest downloadable image, yet there was an update immediately waiting to be installed. That is not at all unreasonable, but it does increase the odds that this use-case might happen to more than “just me”.

8

I do agree that granny is a “extreme” case, but doing things default, like enable backup I can accept, with a default value to where to store it. But only if a user can change the values at will.

But to remove a “choice from an uninformed user”, out of “lessens support burden” or change a “really thought out default value” because “power”-users don’t use the option that are there for their “customization”.

Wanting such a change in a system used by all kinds of people:

  • Those who either not know or c.are
  • The tech guy that edits the number of back-ups to 30, do one per day, stores them in his NAS.
  • The neighborhood IT-guy, works with cars, but is known to “knows his IT”, does a simple reinstallation for “whom ever”, for a cheap buck.
  • The company that sell ad-space on their publicly placed TV’s, who use OSMC as display on a pi3 (or what ever)

I see it as good, back up function is there, the initial value shouldn’t be “taken out of the sky”, and not changed unless deemed needed due to progress of HW or Software. There is a reason why it wasn’t 7/30/365, or built to do incremental every 2 and full the third backup.

I do see the value of an increase in your case, I don’t see it for the Company that pushes an image to their interactive TV once per week. What I’m saying, yes you can change to “keep two”, but don’t force anyone else to change it back to one, what ever their reason.

9

AGAIN,

NONE of your use cases would be impacted by a “default value of 2”. This value is STILL changeable via the settings menu, as it would only be the default for new images, not for an upgrade.

The point I’m trying to make on ultimately why all of your use cases are not affected is because the use cases for even adding an SD card, to begin with, are for backups, and/or local storage of media files, in which case no one would choose a small enough card capacity that would make keeping a 2nd backup file problematic. That’s what all of this boils down to. Even your digital signage example, where the number of media files would be limited, if someone IS going to store media, they’re not going to use a low capacity SD-CARD, and if they use the SD-CARD strictly for backups, then keeping a second backup, would not impact even the smallest of cards!

But, responding specifically to your new use cases: 1, 3, and 4 I respond with the same questions: Would they even turn on automatic backups? if they did, would their SD card be overtaxed with an additional backup?

Case 2: If they have turned on automatic backups and set that to 30, this doesn’t even affect them. It would only be the default value for newly installed images. I’m not saying “force the value to 2” I’m saying, “modify the existing default of 1 to 2” for the build of install images.

And while every single user might not benefit from a default value of 2, enough would, to make it a viable change request, especially when compared to the “cost” of storage of a second backup to all the use cases you’ve suggested.

Your system deleted my older backup file (which held all my custom addons, their default settings and data, etc), because I installed a new image, turned on “backup on upgrade”, without changing the current default value of 1, and then did an immediate upgrade. Fortunately I was able to rebuild the a lot of what was lost (though I did have to repopulate data and the settings, etc.)

Using your “granny” extreme, let’s say the son had changed the setting to keep 3 backups, but granny started poking around in the settings, then just slides the bar down to 1 or 2, and clicks ok. Without any prompt, the “extra” backups are basically marked for automatic delete on the next update.

If you wanted to avoid any and all possible conflicts, then this change request could be to add logic such that any modification of the setting for “backup on update”, or if the value for number of backups to keep is changed, run a check if there are existing files over the value specified, then do a prompt to confirm marking the “extra” files for deletion. That’s just a whole lot of work for something that could easily be fixed by keeping two files as the default.

I just don’t understand why you’re even fighting me on this. Is this personal for you? Are you the one that decided 1 would be the default, and you don’t want to change because of that? Help me understand. I’m on the spectrum, so if there is some kind of non-rational process at play here, then I’m not seeing it.

10

As I said, I see the benefit of doing this, personally. But how ever, I also know that there isn’t just, up the number, for the potential 1000 of user/customers that are limited to the sd/emmc storage size.

As I also said, doing such a change should be validated with such thoughts as “2gb SD card cant be bought / can’t install osmc anymore”. Since I do believe the default value was set with such restraints in mind. So in order to change a default value, you have to make sure old user/customers, not even might get locked out of the product, until a change in policy like “stop support for pi1/atv” which where reason for other comparable restriction earlier.

Again I do understand where you come from, and I’m not emotionally against it, it feels like a good move in the future, as long as it doesn’t alienate current users/customers, whom may have a tailored version with a lot of other system software eating local resources. Built a company using 500 pi3, with a minimum 2gb SD card(to save initial cost), with custom graphics, custom remote administration, all media content centralized, db and all. but just have 120 kb left on the card after a media sync.

I can imagine up 1000 scenarios where it “could become a problem”, In my mind since I don’t do these calls, it’s a bad idea to change something that has worked for most users/customers.

What I’m saying, if you have to edit the setting for automation, you should also change the def value if you think it can become an issue, like placement, number of copies?

Don’t fix “no existant”/“low likely to occur” problems, because that can and often does, generate non thought of complications. Especially if we have to write new logic in a working backup automation.

11

I vote for default of 3

1 Like
12

I’m trying to understand exactly how the problem occurs. (Arbitrarily increasing the number of backups kept feels like the wrong answer, although simple enough.) It should only be an issue where the re-install is a different (major) Kodi version than the one which was backed up. Normally you would:

  • use a blank SD card to reinstall OSMC to the latest release
  • restore your backup from wherever
  • enjoy

But if the ‘latest version’ install image is behind the latest release (which happens only for a few days after a OSMC release), you would have to install the latest version available (ie previous version) and update that before restoring your backup. The manual update you would do would not generate a new backup. It’s only automatic updates that generate automatic backups (it says in MyOSMC).

What you encountered seems to be a very rare combination of circumstances. Or am I missing something?

13

@graham is again hitting the nail on the head.

If we can understand the circumstances around the issue, someone can do a better job of prioritizing the work effort involved, expected change for current user/costumers, the + value of the work needed contra the actual work done, meaning something else in the todo-list is on the backburner for a developer.

Since I personally understand your point, I try to look at it from another perspective.

My perspective, in order to turn on autobackup, you also get a chance to say how many backups to keep and where to store them? A user does this. 5 mins job at the most.

Change a default value in another perspective, what needs to be change, is there possible regression, how to avoid regression, is there need for logic, who did the logic last time, is that person available, who can take that ball and roll with it? How much trial and error time is enough for stable release? Will a such a change validate time taken from other pressing matters? How much time is expected to go to such a change?

So I say, great idea i see your point, but does it merit:

  • anything going wrong for even 1 or 2 current users
  • time used on this idea, instead of doing things in the project that has all ready passed the “needs to change and who does what”-criteria?

Saying no is easier then to invest the time now, so mark the idea in the next-todo-list

So I reply as I have =)

Edit: seems like I’m misinformed, I thought that autobackup was a “opt in”, which in my mind makes my point a bit redundant. But if it’s on by default, changing the def value is even more of a “can regression occur” even more pressing matter!

17

So I just rebuilt my Vero4k last week. I used the installer to install the latest image.

Before I even completed the first-run setup, I received a popup that there was an update that needed to be installed (even prompting if I wanted to continue). I said no to that request because I wanted to complete the setup before running any update. So I completed the setup, rebooted the box, and then allowed the update.

So I do not consider that a rare combination of circumstances?

18

OK, so the updater is a bit zealous. We could look into that. But when you ‘complete(d) the setup’ that must have included both enabling auto backup on update and setting the backup location for it to nuke your existing backup. Was that the sequence? (IIRC setting up backups is not part of the install walkthrough).

19

the + value of the work needed contra the actual work done, meaning something else in the todo-list is on the backburner for a developer.

{sigh} THIS is why the whole point of my request is that what I’m asking for is achieved via a single change of the default value of settings.xml

Line 66:
<setting default="1" id="tarball_count" label="32108" option="int" range="0,1,25" type="slider"/>
change to…
<setting default="2" id="tarball_count" label="32108" option="int" range="0,1,25" type="slider"/>

As I’ve already stated, the BEST way to solve this from ever being a problem is via adding “on-change” code to the setting menu script, so if a value is chosen that would result in files being deleted the user receives some kind of popup warning of that fact. THAT is a lot of work, and thus meets your criteria for “something else going on the backburner for a developer”, what I’m requesting does not.

20

Yes, you are correct. After completing the initial setup (but before rebooting to run the automated update), I enabled autobackup and set the location for the backups. Why I did not notice and thus change the value for number of backups to keep, I can not remember, but that’s probably because of my assumption…

WHO THE ■■■■ AUTO DELETES FILES ON EXTERNAL MEDIA WITHOUT SOME KIND OF PROMPT?

{deep breath}
Sorry, let me try that again…

…but that’s probably because my assumption that any settings change that would result in any file(s) being auto-deleted, would have some kind of pop-up warning to let me know that.

{deeper breath} but again, that would take a real code change to implement, so what would be the balance point between the negative aspect to changing the default vs it’s positive impact?

I don’t know, like maybe keeping a default of two backups? So that way, at the very least the last backup I had previously stored on that media, wouldn’t be automatically deleted, if I forgot to change the current default of 1.

Sorry, the impression that I’m getting is that I’m trying to institute some massive change that benefits only me. Trust me, I’ve already made a label that reads “RENAME ANY BACKUP FILES PRIOR TO RESTORE/FRESH-INSTALL” and stuck it on my vero4k with an arrow to the SD port! So, personally, I don’t give a… crap, if you institute this change or not, but as I have pointed out more than once, I do not believe my situation to be unique, furthermore I believe as more people replace existing hardware (the devices ain’t getting any younger!), that is will be an issue that you’ll see more often.

21

So, at this point, I’m done. I’m un-watching this thread.

Institue the change, or don’t. I’ve got my sticker, so this won’t happen to me again.

22

Incorrect. As I said, the change is trivial. But I for one am just trying to understand the sequence of events you followed so we can put some suitable warnings in the appropriate places and get the wiki more accurate. Thanks for your patience.

1 Like
23

Yeah that is a real issue, there could be logic to over write a local back up, with out prompt, if user agreed in settings before hand, but never a non local-resource (Everything other than emmc or in pi SD-card, in short boot medium). So as I said earlier, I see the need, but to do a functional change in a working environment. Often takes more time the just change the value.

And add to that I know it’s a small team of active people in OSMC-dev, and have gathered that there are like A LOT in the pipe and thanks to upstream updates, work on development of unique OSMC stuff, like “The Legendery MyOSMC-II” often takes a backburner. So when an issue, that is in fact a convenience problem, eg user missed an actual setting. I don’t dislike any user for suggesting improvements, but the lack of understanding how much work there is in the background to get things into the shape “Sam keeps this ship floating”, is a bit over whelming. So I’ve started “venting” when, even if it’s thought out suggestions for improvement, a real good idea, that “just needs two lines changed”. I feel the need to speak out, often in a matter that might be perceived as “uncaring/dismissive”, I’m often accused by my second half to “never care”, since she feels that I’m detached, objective, argue the big picture instead of the details.

In short @ZacWolf I get the idea, but I see it as “another one on the blackbook-todo list”, and try to lower expectations =) So next time I think I lead with this statement:

“Another one for the blackbook-todo list”