After desynced database - delete local database and "repair" DB -> delete all destination backup files

I’ve a lot of backups in destination folder (webdav) with monthly 10 years retention and weekly 3 month retention… so i’ve a lot of important backups at the destination.
After a lot of errors with the local database and destination files i’ve run repair jobs but without luck.
So i’ve recreate the backup job and run backup, but instead of the created “windows backup service user “sys_backup””, i run the backup with my own windows user and the new backup jobs have failed, after the service user has tried the backup (sure, the backup db was wrong) and i copied the db file of my user local appdata to the backup user local app data -> in the db settings of the job, change the db file path to the copied file and save, run repair and try to start backup but it failes, so i click db-delete and repair -> all destination backup files are lost.

Why the backup job delete all backup files?

Does the destination have a recycling bin or anywhere else deleted files might have gone to for awhile?

Do you recall any specifics? I assume this predates the huge sentence that’s the rest of the paragraph.
Could you write that in a chronological order? Things like “after the” make me think it’s not ordered now.

It looks like something went wrong running as you, and something went wrong as service user, but the specifics aren’t mentioned, and the sequence isn’t clear to me. Please write this up as well as possible.

If you haven’t yet tried to Recreate or Delete and Repair the database, it might still have some evidence.
Repair gets logged just like Backup does (probably subject to same issue that early failure might not…).

One suggestion of the write-up is that Repair did the deletes, but this should also be visible in logs using Complete log --> BackendStatistics --> FilesDeleted. There might be other useful information too.

Another log to look at is the job’s Show log --> Remote which will give timestamps, but not the operation.

Creating a bug report and posting a link to it is another option, so someone else might look at the history.
Note that if you’ve already deleted the old local database, the history got deleted along with the database.

What Duplicati version is this, and on what OS?

No :confused: Not today, but i have planned a backup of the backup…
The backup files are not “critical” but the destination should have one backup of every month and many weekly backups, if someone need a backup of a special day (game server backups).

I have to restore/import the “Database” of the old Backup Task to find the “delete files” logs.
I try to do this in the next week, including a step by step list of the steps i did and post it here.

The first delete of destionation files was after an update - version “year 2018/2019” to
The second yesterday with version
Its a Windows Server 2016 OS.

You’re saying all the destination files disappeared instantly after update? I haven’t heard of that.

A certain amount of delete is normal as data goes obsolete and space is recycled by compact.

where originally it sounded like Repair was the suspect, but I’ll wait for the writeup of the history.

There’s one problem that can happen when people restore an old database and run the Repair.
The newer files look like they don’t belong there (database never saw them), so they’re deleted.
The only way I know of to delete all of the destination files is to ask for that while deleting the job.

Regardless, if all destination files are truly gone, the backup is gone, and we can just study how.