[Bug] Backup amount is not followed properly

[HyperCriSiS]

Hi, I have set the maximum amount of backups to two. It works only for some apps, for many other apps there a kept 4,6,10 or even over 30 versions.

• Device: Zenfone 8
• Android Version: 11
• ROM: Lineage
• App's Version: 8.3.2

Is this a bug or did I configure something wrong?

Thanks and regards Hyper

[HyperCriSiS]

Also many unnecessary backups are made. Very often apps are backed up again completely also there was no change.

[HyperCriSiS]

Max backups to keep is set to two.

[ovizii]

I can confirm, I just noticed this problem too with Neo-Backup Version 8.3.4 btw. I am only doing manual backups to local storage.

I have set up revisions to "1"

Neo-backup seems to think there is only one revision present:

While in reality my file manager shows 4 existing revisions:

[machiav3lli]

The cause of your issues is having corrupt backups (see the lack of the .proprrties file for most folders).

[ovizii]

Thanks for the pointer, I didn't know each backup had a properties file associated.

I manually checked all my backups and basically only the biggest 3 which are many GB in size had this issue. I vaguely remember the first backups I tried failed but since Neo-backup never showed more than 1 backup for them, it never occurred to me to manually look into the backup folders.

Would it make sense to build a check into Neo-backup which checks the backup folders and logs or notifies about backups with missing properties files?

[HyperCriSiS]

The cause of your issues is having corrupt backups (see the lack of the .proprrties file for most folders).

I have many different combinations. App backups with:

• many folders and only two prop files
• many folders and same amount of prop files
• two folders and many prop files
• many folders and more prop files

Something is going very wrong. :(

[hg42]

Would it make sense to build a check into Neo-backup which checks the backup folders and logs or notifies about backups with missing properties files?

actually there is such a feature, but it is still kind of experimental:

• Long press on title (e.g. Homepage)
• choose tools
• renameDamagedToERROR

then, if you think this is all ok, you can use deleteERROR to remove those renamed items.

Otherwise you may delete what you want manually in the folder (which is easier now, because they are sorted), then use the undoDamagedToERROR, which renames the remaining items back. The marked items are still not picked up by NB, but maybe you want the files for other purposes. Note: encrypted backups (*.enc) cannot be decrypted at all without the propeties file, because it contains a so called "salt" (an additional random key).

[hg42]

* many folders and only two prop files

this should be the normal case when unexpected things happen. The properties file is only written when the backup was considered successful, so if you or someone else kills NB, NB cannot remove the running backups (usually about 8 in parallel) and the properties files would not be created.

* many folders and same amount of prop files

that's the normal case, but it seems the housekeeping didn't work. This should be a thing of the past... Are you sure you didn't use the lock icons of those superfluous backups? There is one other case that could look like this: if some properties files are empty or damaged.

* two folders and many prop files

now, this is extremely unlikely. It can only happen, if all the backups worked. All commands returned a success code and everything else also worked, only then a properties file is written. Even if the properties fiels are empty or damaged, the fact that NB tried to write them is enough to conclude NB thought the backup was ok.

So, does someone delete folders?

Note, unless restoring, NB is only interested in the properties files. It reads them and if they contain correct infos, those are presented as the backup item.

* many folders and more prop files

I not sure what this one means. Again if there are more properties files than folders, someone deletes folders.

Something is going very wrong. :(

agreed, but what?

• Some of the cases could come from disk full events (the ones where you have more folders than properties files).
• Housekeeping works with the number of detected backups. This means properties files that have valid contents. So I guess many properties files are invalid (e.g. empty or damaged structure, they need a pair of {...} and all expected entries in between, some are optional).

[HyperCriSiS]

For now I deleted the whole backup folder. Let's see what happens :)