Hello,
I recently installed a new antivirus, but did not exclude my backup drive before scanning (since my old AV had started to detect false positives.) Bitdefender decided also that some archives contained malicious content, and so deleted some of the archives.
If your Source screen has filters, e.g. to exclude things, delete them for this operation in Commandline.
You might have tried to write a CLI line from scratch. Better is to start from an Export as Command-line, because that will pick up essential information that matches GUI backup – including a lack of encryption. Encryption for local files may seem pointless, but might have kept the antivirus from disliking file content.
I don’t think verify fixes things, however from testing it should pop up an error if any files are truly missing.
What’s worrisome is the file of errors that you posted. A few of your files are mysteriously the wrong size. What are the dates on those? Maybe instead of deleting the whole archive, the AV deleted a few zip parts. That would mean you’ve lost whatever data was there. You can use The AFFECTED command on them.
Example of use here. Possibly just hiding the 8 files by prefixing name with hidden- would let you run list-broken-files and get the same sort of output without having to retype names into the affected command.
If you can stand losing older file versions, you could delete the Database and backup files for a fresh start. Adding encryption at that time would probably keep the AV from handling what I guess are false positives?
but it still fails and tells me that filters are not supported.
Bitdefender is able to delete parts of archives, so it is likely that
happened.
–
I agree that the file sizes look wrong, I assume this only applies to .dblock.zip files, and not to dlists? I’ve attached a picture of some dlists also.
If I really need to, I’m happy to restart my backups.
Thanks!
There is still an exclude filter on the screenshot. Delete filter using x button.
AV will clobber whatever it dislikes, however unencrypted .zip of dblock might look more suspicious.
The dlist and dindex files are pretty much just text whereas the dblock has blocks from source files.
Reading images is a really hard way to find file times. Explorer or the dir command is far easier…
I did find three, rather close together which suggests this is the AV damage. Is the time about right?
I’d hope so since I read them from your screenshot. It’s the other 5 that I didn’t find. Are the other 5
near these, with all 8 at the time when the AV ran? That would solidify the idea that AV did damage.
OK, since I had the file listing (lots of files…) I looked up the other 5, and the times are very nearby.
Having the list with a nice time format at the left also made it easy to sort the files by time.
Typically a backup churns out files at kind of a steady pace, and does a dlist near the end.
The view here is different. It looks like maybe the AV corrupted old files between backups.
You can see the 8 wrong size files sitting by themselves seemingly between the backups:
It looks like it’s not going to trace issues back to source level just based on files being the wrong size.
You can copy and paste the 8 names into the affected command, or hide the 8 for a list-broken-files. Generally I just rename with a prefix, e.g. hidden-, but for 8, moving them to another folder may work.
Test result seemed to be similar in either command. You want to see what impact loss of files means.
If you prefer the affected command, the easiest starter is Commandline and change from backup to list-broken-files, then change the source file list to name the 8 damaged file names, one per line.
Or do it both ways if you like, to see if you also get similar results. If acceptable loss, then just take out damaged files (they are effectively taken out by renaming or moving), and run a purge-broken-files.
Disaster Recovery gets into these areas, and topic applies here because you have a corrupted backup.
Sounds good. I hope it goes well, and that your AV doesn’t damage any files again.
If you ever do need to restart fresh, encrypting the backup would probably prevent.
If you’re super curious you could examine the seeming damage in some other way.
Because you are not too concerned, easiest path might just be to purge those files.
I ran the PURGE-BROKEN-FILES command, but it doesn’t seem to exhibit the same behaviour as in the Disaster Recovery doc. PURGE-BROKEN-FILES (github.com)
Ah, I copied them instead of moving. My mistake.
After running LIST-BROKEN-FILES again, it shows the list of affected files.
I then ran PURGE-BROKEN-FILES, but it returned
Listing remote folder ...
Backend quota is close to being exceeded: Using 851.31 GB of 931.51 GB (79.88 GB available)
ErrorID: CannotPurgeWithOrphans
Unable to start the purge process as there are 184720 orphan file(s)
Return code: 100
This seems to be pretty rare. I’m sorry it happened to you. Of the two reports I could find, this was also AV damage, though I don’t know why AV damage would be anything special. Regardless, it had a workaround:
When on your Database page, instead of simply doing Recreate you could consider making a copy of the database beforehand just in case something goes wrong in the Recreate and we want to try old DB again.
Maybe a Repair would help, but it’s never clear what Repair can fix, and it sometimes harms destination. Recreate doesn’t always work well, but at least it doesn’t change the destination (the actual backup data).
You could also post a DB bug report so someone can maybe make some sense of its damage, but it’s not guaranteed that will be possible, and it probably also won’t lead directly to knowing how things got that way.
To benefit anybody following this chase, I think this is the detection code. There’s one table listing files. File may appear multiple times if different versions exist. Each of them should be in a different table organized by backup version (which contains files). In this case, some files did not have a containing backup version.
