Changes in backup files (*.dlist.zip.aes and *.dindex.zip.aes)

Where can I find information about which backup files (*.dlist.zip.aes and *.dindex.zip.aes) were created, deleted and changed during backup processing?

Welcome to the forum @JRR

<job> → Show log → Remote but why do you care? It’s very far removed from source file changes.
The files you mentioned are just created but not changed until deleted, so there’s another question.

How the backup process works

Introduction is background info.

Hello

Changed ? None. Files are replaced, never modified.

For creation and deletions, this Sql query could be of help:

select ro.operationid, datetime(operation.timestamp,"unixepoch") dat, ro.operation, ro.path
from remoteoperation ro
   join operation on (operation.id = ro.operationid)
where 
ro.operation in ('put','delete');

as long as you did not recreate the database at some point. If you did, the history is lost.

Thank you very much for your quick response.
I use a cloud storage service that does not offer any file transfer services except its own application. So I make a duplicate backup locally and “manually” transfer the files that were created during the backup (sorted by date) to the cloud, but I was having difficulty finding the files that were removed.

Thank you very much for your quick response.
I didn’t imagine solving it this way, very creative.

General concept is good, but not totally reliable because OperationID might reflect a later row update. Backup that runs normally is likely better off than if interrupted by boot, but those invite other troubles.

Since you seem amenable to database-crawling, RemoteOperation table is probably immune to the above weird effect of a late update, however both are susceptible to transaction rollback when killed.

If by any chance rclone supports your storage, easier plan is to let rclone sync do its usual thing…

EDIT 1:

Topic subject didn’t talk about dblock files, but those are essential otherwise you don’t have file data.
Only doing dlist and dindex might let you recreate database, but source blocks wouldn’t be available.

EDIT 2:

Another option that doesn’t use the database, so is not subject to potential uncertainties in reporting:

log-file=<path> and log-file-log-level=information, and then look at BackendEvent for Put and Delete.