Is Duplicati Filesystem Agnostic?

Is Duplicati filesystem agnostic? For example, I have backed up files while they are on a EXT4 HDD in a NAS running Debian. If I were to switch the HDD’s filesystem to BTRFS and then copy the files back on it, can I reuse the same backup job afterwards?

Yes, that should work. I believe the only time you cannot continue an existing backup is when you change the OS Duplicati is running on (when it results in a different path separator character, eg change from Linux to Windows).

Does copy mean copy from another filesystem, or restoring from backup by Restore or Direct restore?

It’s not clear if you plan to use the existing backup database, or if it’s on the drive that’s going to BTRFS.
If this is “Direct restore from backup files”, then remember to Export and save the backup configuration.

Aside from safety worries (test your backup well, if plan means deleting originals), there are timestamps storable at different resolutions on different filesystems. Duplicati’s remote files use 1 second resolution, whereas the database has fine resolution. Different resolutions aren’t a big deal, but can add processing.

Thanks, for the purpose of this, there will be no changes to the base OS

Thanks, I meant in both ways. Specifically two different cases:

  1. I copy back the files via manual copying (e.g. using the copy command). Then I resume backing up with the same backup database and job (i.e. no new job will be created)

  2. I use the Restore functions to get the files back. Then I resume backing up with the same backup database and job (i.e. no new job will be created)

May or may not have original timestamp precision (depending on resolution of FS it was copied from).
ext4 resolution reportedly varies with inode size. You could probably also stat a sample file timestamp.

This should not have any timestamp issue, but does pose more risk if the only data copy is the backup.

Thanks, I think I’ll stick with EXT4 first for the time being, while also trying to get more HDDs so that I can test this timestamp issue more properly and safely