When installing duplicati on a Synology NAS, the configuration is stored in /root/.config/Duplicati, why not using the application store in /var/packages/Duplicati and put the config in an etc subdirectory ?
While I understand why it would run as root to be able to use my filesystem snapshot feature, there’s no reasons to not use the proper configuration path.
Neither place is good, in my opinion. The root filesystem on my Synology is quite small, I think only 2 GB. If you back up a lot of data, your Duplicati sqlite files may grow larger than that. It’s better to store them on your disk array, eg /volume1/duplicati
Before I switched to using Docker Duplicati on my Synology, I created a symlink so that /root/.config/Duplicati was redirected to a folder on /volume1/
Have you tried using snapshots? As far as I know Duplicati only supports LVM snapshots. My Synology uses btrfs which has its own snapshotting feature, but Duplicati doesn’t integrate with that. I know LVM is still present but I don’t know how snaps there would interact with snaps at the filesystem level. Kind of a moot point now that I’m using Docker - I doubt it could trigger snapshots.
But one of them is what Synology expect from developers.
Creating a share specifically for duplicati is wrong, if we need more space, we can use /volume1/@appstore/Duplicati/etc
By default DSM doesn’t use LVM, but the tools to create LVM volumes are available in $PATH.
If Duplicati could use Btrfs’ snapshot features it would be great for sure.
I didn’t suggest creating a share, just a new folder in /volume1. If you create a folder manually (via ssh for instance) it doesn’t show up as a share.
I am not sure about @appstore location - would the data there survive package uninstall/reinstall? I haven’t checked recently but I think uninstalling a package wipes out data in the @appstore location.
In any case your point is valid - the current location is not ideal on Synology.
I don’t think that’s true, unless the default changed recently. I set up my NAS a bit less than 2 years ago and it does layer btrfs on top of LVM. I guess Synology just has more confidence in using LVM for the RAID portion… not sure…
It’s possible, there are past threads about it!
Here it uses btrfs on top of mdraid, no LVM.
Guess it depends ?
/dev/md2 on /volume1 type btrfs (rw,relatime,synoacl,nospace_cache,auto_reclaim_space,metadata_ratio=50,subvolid=257,subvol=/@syno)
Since Duplicati allows you to run scripts before and after backup, one could mount the last btrfs snapshot and backup that, something like this could work.
subvolid=btrfs sub list /volume1 |grep "top level $ID_of_the_share's_btrfs_subvolume" |tail -n1 |grep -oP 'ID \K\w+'
mkdir /tmp/backup_source
mount -o subvolume=$subvolid /dev/$path_to_device /tmp/backup_source
Restoring would require mounting the live subvolume instead of the snapshot subvolume there, and you will need to unmount /tmp/backup_source after backup or restoration.
But this is untested, only theorical.
No it won’t, but the path you are supposed to use wouldn’t too as far as I am aware of.
Yeah maybe it depends on if you use RAID1/5/6 instead of SHR/SHR2 or something. I use SHR2 on my NAS.
If the default changes, it needs to be some location that won’t get wiped out due to DSM upgrades or package uninstall/reinstall (upgrades). I am not familiar with developing DSM packages and what Synology best practices are for storing data like this. there must be some place they advise…
I do not lose Syncthing config when upgrading the package, but I lose it if I uninstall and reinstall.
Maybe a good point to start ?
I agree with @Magissia
Duplicati on DSM should install its settings into the proper app location.
In DSM Package Manager, admin can choose where packages should install (even create separate volume on the NAS for package locations). If the package if prepared properly, then it can allow the DSM settings to determine on which volume the app should install (and can even be moved by the admin using DSM).
The data in this location survives upgrades (even if package is upgraded by uploading a new .spk manually - provided the app is packaged properly).