[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 :)

[brupec]

Hello all, same problem here with latest 8.3.6

Various backup kept even if version number set to 1

[hg42]

did you read this thread? from your description there are still multiple possibilities

do you see multiple backups in NBs backup list of the app? or do you look at it with a file manager?

are there more properties files than backup folders? or are there more folders than properties?

In DevTools / infolog you can see folders without properties or vice versa and a count of such suspicious items. A normal output shows only a few messages per scan. Use refresh button, then long press title and select infolog.

A successful backup looks like:

name/* name.properties

I'll try to summarize:

the backup is created in it's folder named with date and time. If it is successful (from POV of NB), then it creates the properties file.

if the properties file is missing, the backup was interrupted and NB was killed in some way. That's because, if NB detects that the backup failed, it does not create the properties file AND then deletes the folder. So if there is a folder and no properties file, somebody prevented NB from cleaning up.

Battery savers come to mind, killing apps that run too long (and a backup usually IS a long operation).

If NB shows more backups than configured, you may have locked backups (red and closed lock symbol). Otherwise it would mean someone kills NB, before it can clean up the backups that are above the limit (this is done only after each app backup for that backup only).

In either case, someone in your phone is killing NB. This can be cleaners, battery savers or ROMs (some manufacturers prefer to kill apps, instead paying for bigger batteries). And there are a lot of apps that think killing apps while they work is a good idea. Think again!

[brupec]

Hi, thanks for your answer. I checked and have various cases. Sometimes no prop file, so maybe program was indeed killed,even if I don't see how as I have stock pixel, no battery management app and app is configured to not be power saved. Also for instance in that case (enclosed screenshot), we can see prop file is created (but 0kb...) and kept with the folder, even if I see only one backup in app.

Isn't it possible to add specific task that would automatically delete folders without prop files and prop files with 0kb? Even if I understand it is not the best, but in my case neobackup folder get huge and then storage full, and more backup failed.

Le jeu. 4 juil. 2024, 21:50, Harald @.***> a écrit :

did you read this thread? from your description there are still multiple possibilities

do you see multiple backups in NBs backup list of the app? or do you look at it with a file manager?

are there more properties files than backup folders? A successful backup is like:

name/* name.properties

I'll try to summarize:

the backup is created in it's folder named with date and time. If it is successful (from POV of NB), then it creates the properties file.

if the properties file is missing, the backup was interrupted and NB was killed in some way. That's because, if NB detects that the backup failed, it does not create the properties file AND then deletes the folder. So if there is a folder and no properties file, somebody prevented NB from cleaning up.

Battery savers come to mind, killing apps that run too long (and a backup usually IS a long operation).

If NB shows more backups than configured, you may have locked backups (red and closed lock symbol). Otherwise it would mean someone kills NB, before it can clean up the backups that are above the limit (this is done only after each app backup for that backup only).

In either case, someone in your phone is killing NB. This can be cleaners, battery savers or ROMs (some manufacturers prefer to kill apps, instead paying for bigger batteries). And there are a lot of apps that think killing apps while they work is a good idea. Think again!

— Reply to this email directly, view it on GitHub https://github.com/NeoApplications/Neo-Backup/issues/797#issuecomment-2209899732, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAUS7YPK3DWAA5XDJKOBENLZKYCYFAVCNFSM6AAAAABKMLES62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBZHA4TSNZTGI . You are receiving this because you commented.Message ID: @.***>

[hg42]

When I implemented renameDamagedToERROR / deleteERROR, I thought I would get responses about how it works. It was intended to do this automatically when it works stable. I didn't get much feedback, maybe it works good and nobody needs to complain.

Unfortunately in the current state, scanning (where this detection is part of) happens after each single backup and it's quite normal, that folders without properties exist, because in parallel, other backups are created. It's not guarantied that scanning happens without anything running in parallel. So this might delete backups before they are finished and we should stay on the safe side (I think deleting backups is a nogo, even backups that may be invalid, at least when they are not encrypted).

[hg42]

the zero size properties indicates, that your disk was full... Though, I always wonder how this can happen. The file is very small and in case of disk full, writing the much bigger archives should have resulted in a system error before. In that case the properties would not be created. So the archives would be completed and the there is no space left for a few kB? that's extremly unlikely (actually a probability of the size of the properties file divided by the size of the backup, I guess 1/1000 or less).

[brupec]

OK for the disk full problem.

For the renameDamagedToERROR / deleteERROR it seems it worked good for me.

Maybe would be good to have possibility to autorun this combo on a specific schedule, getting that way sure it happens outside of the other tasks defined timeslots ?

Thanks for your support, neobackup is fantastic.

[hg42]

I think, the data is too important, my plan is a kind of locking mechanism...but this needs some more brain thrown to it...