The usual backup file output to the destination is a stream of dblock files of the default 50MB size with a small dindex for each dblock and a dlist at the end whose filename contains the date and time of the backup’s start.
Because it’s no longer 20190117, the dlist you see (is it new?) seems like it would be from before. If this is the empty drive swapped in, repair can often rebuild missing dindex and dlist files from the local database, but it can’t rebuild dblocks. These contain the actual backup data, and I don’t think a repair will do backup though there’s an issue currently where starts of non-backup operations are announced in the UI with “backup” word.
Could you check the drive with the first backup, to see if it has a file by the same name? That would fit theory.
Every backup saves changes from the one before. The first backup has a lot of changes from nothing at all.
Complete, incremental or differential gets into this some, for those who know traditional backup terminology.
How the restore process works says how files are rebuilt from blocks. There’s no full/differential/incremental, and disaster recovery only needs one drive. Other drives would be additional complete backups (for safety). Sometimes off-site storage needs can influence plans. If a disaster takes out the primary, how old is too old?