So I was looking for a decent replacement to Crashplan (which was getting ridiculously expensive) in a household with a Mac, Manjaro and Ubuntu computers. Especially my Manjaro laptop need solid backups so for now that’s the one I experimented on.
I had connected a 4Tb WD drive to the USB port on my Netgear mesh wifi extender and bought an identical second 4Tb drive with the intent to swap them on a monthly basis and always have one stored with family somewhere else.
After some permissions issues and a bit of tinkering with file systems I finally landed on NTFS and the share automounting on boot through /etc/fstab - mountpoint /mnt/backup
Initially I downloaded Duplicati from AUR but that install gave me considerable grief with source directory /home/mike marked with little icons of a folder with exclamation mark. Also the backup stalled out with many permission errors.
I ditched the AUR version and got the Debian version directly from the website, unpacked it in /tmp and manually moved the appropriate files to /usr /lib and /etc after which I started the server with systemctl
I did get a huge (50Gb) backup of my home directory done on my first try although I spent ages looking at the progress bar while the system verified the backup in the end - that seems to take for ages but finally it worked! Also created one more job for my digital photo storage and that went considerably faster seeing there are only jpeg and raw files in there.
My lesson learnt is to stick to the official source. Although I have the greatest respect for the packagers who contribute to the Arch User Repository, in this case repackaging almost caused me to give up on what turns out to be really solid software.
Welcome to the forum. Thank you for sharing your problem and solution.
This caught my eye. Duplicati won’t like it if you swap the back end. It expects to always see all the backup files and will fail the job otherwise. One workaround is to have two backup jobs, each configured to back up to a different external hard drive. You’d have to run the job that corresponds to whichever drive is connected. A better solution (IMO) is to not swap the drives. Instead you could regularly bring the second drive on site, sync the contents with the first drive, and then take it off site again. Just an idea.
Arch packagers helped security and hurt usability by running user=duplicati group=duplicati.
Maybe that’s what you saw. It cuts risk if web server gets hacked, but denies lots of access.
Thanks for that! I hadn’t realized that there is a requirement for continuity of files. Syncing a disk or even imaging it seems like a better solution indeed.
On the subject of using SMB as protocol - not so nice on the Mac. Turns out writing from OSX to a networked drive via the smb protocol is way slower than it is on Win or Lin. So I dumped my current setup and conmnect the 4TB drive to my Asus RT-AC68U router downstairs which offers FTP access. Work like a treat and about 3 times as fast as samba.
On the subject of OSX, I updated to the latest canary version in the hope to get rid of this annoyingly long stall when “verifying files” at the end of a backup. Turns out the update function should not be used on the latest one and I found out late. With the help of this forum, updated mono, re-dowloaded and installed Duplicati and removed the ~/.config/Duplicati files to avoid running duplicati as the very user I was trying to backup - with instant access issues as result.
All’s well that ends well - I now have both computers fully backed up - max runtime on the MAC (a complete user) was around 2 hours for some 95-of Gb
Depending on your use case, you can also run the service as a specific user (assuming that you only want to back up files that user has read access to):
I don’t run Arch or its derivatives, but if you mean change AUR package to do this – Duplicati team can’t, unless you know of a way. If so, please give some details. Or maybe someone can ask Arch packagers.
Asking the packagers to say to remove it probably wouldn’t go over well. They intentionally put it there… Perhaps some way to tell people that they need to take some action (e.g. adding supplementary groups) would be a reasonable approach if there’s some way to get word out. But I don’t know Arch packaging…
Agree, it was definitely intentional. If someone doesn’t agree with the user/group settings, it’s simple enough to edit the duplicati.service file before running makepkg.
Really doesn’t matter whether intentionally or not but a heads-up would definitely have been nice. Oh, well, I can’t complain as I managed to use the .deb from the website just by copying over stuff to its rightful position under /usr
For now, this seems like an edge case which does regretfully have the power to put some people on Arch or Manjaro off from using a really nice bit of software.
Anyway, I dumped €20 in the little donation box to keep this worthwhile project up an running. Small stuff but hope it helps.
