Short answer:
I’m surprised you made it this long without things blowing up and yes this will cause problems. Possible workarounds, make a backup job for each day and run each respective job on it’s day, use my powershell script, backup up to a single drive then manually copy the backup files to another drive.
Longer answer:
In spite of copying the database, the database is missing key information that’s stored in the database on the other drive from when the backup last ran to that drive and not this drive. The changes to the dblock files and database will not be reflected properly and things will eventually go wrong.
FYI: The database is strictly a speed thing you don’t need it to recover your data, the whole database can and will be rebuilt if needed from the backup data files, you can back it up but it’s actually more work to deal with an existing moved DB when it comes to restoring.
I have an external USB drive for each day of the week for all the reasons you mention. I also initially planned on using Duplicati in the same way as you did but discovered fairly early on that it wasn’t going to work as planned at which point I created the PS script (linked to above in the short answer).
So now I have a job for each day (all with the same source settings other than name) that will only backup to it’s respective drive thanks to using the alternate-destination-marker option, the jobs are then scheduled using the Task Scheduler in Windows. There are other ways to make this sort of setup work but the key is that the job and it’s database are unique to each drive/destination. The script also determines which days drives are connected and if more than one is connected will use the least recently used drive (vs the most recently used) and runs a backup to that days drive and it all shows in the GUI.
If you have any questions, ask away.