Using CLI on headless linux server

Hi, new to duplicacy (and still a linux newbie)

I’m running a headless debain (dietpi) homeserver, and will use the duplicacy CLI.

I’ll have various questions, so thought could use this thread to document Q&As. Bear with me, they’ll be some noob questions,

I plan to use storj for the cloud storage backend. This guide to set things with init command look correct?

When doing a subsequent backup, and not having to retype:

  • S3 Access Key ID
  • S3 Secret Access Key
  • storage password for s3

The guide indicated in the above link uses the command:

duplicacy set -storage <storage name> -key -value

Though isn’t this insecure/info saved as plaintext?

Additionally, my understanding to store passwords securely via gnome-keyring duplicacy method doesn’t reliably work with headless servers. And I haven’t found an alternative secure method to store keys & password. (That is, if my homeserver box - which doesn’t have an encrypted OS - was stolen, and someone tried to read the content of the disc, I would want keys and storage to be unreadable).

Any advice will be appreciated.

Ensure you have enough RAM — depending on the number of files per backup duplicacy can be quite memory hungry.

Duplicacy support STORJ natively. There are pros and cons in using S3 gateway, both your own or STORJ provided ones, and they should be evaluated separately. That tutorial just describes how to configure any s3-compatible storage, but so does the official quick start Quick Start · gilbertchen/duplicacy Wiki · GitHub and built-in command help.

The file is readable by duplicacy. But so is the data being backed up. If your server is compromised – your data is as well.

Can’t comment on linux keychains, maybe someone else will chime in, but on macOS it works quite well.

However note that use of keychains only ensures that only the application with the specified hash can read the keys. Which means the attacker can still do everything duplicacy can do with your backup, including deleting recent revisions by calling asking duplicacy to prune with carefully crafted parameters.

This is an unnecessarily strong and unattainable goal unless you have hardware key storage. You can use Mac mini for example, or just setup the system in the way that keys and credentials are useless for the attacker.

For example, generate cloud storage credentials that can only add and read files but not delete. The support for object lock would help here but it is not yet implemented: Is S3 Object Lock supported? - #2 by gchen

Neither you nor attacker will be able to run prune and/or delete data with these credentials, the backup will be effectively immutable. This is an example of accomplishing this with Backblaze B2: Backup Immutability - Object Lock support? - #22 by tallgrass. With STORJ you can create access grant or S3 credentials that prohibit delete:

I’m not sure if write permission allows overwrite, would be interesting to check.

So, this will protect against modifications and deletion. To protect against data disclosure you can use RSA encryption to encrypt your backup, to prevent the attacker that got full access to your PI from also reading your backups: to decrypt and restore data you would need to provide private key, that should not exist on the machine that is only expected to do backup.

But then again, if attacker steals you pi along with your storage server – it already got all your data.

This is all sounds like a massive overkill though. What is the attack vector you are trying to protect against? If the adversary is targeting you specifically to the point of scrubbing credentials from a raspberry pi – I’m sure there are other, much less high tech avenues to get you to provide all the passwords and biometrics “voluntarily”

1 Like

Ensure you have enough RAM — depending on the number of files per backup duplicacy can be quite memory hungry.

I should have been clearer, homeserver uses dietpi OS (essentially same as headless debian with tweaks), which is run on a re-purposed qnap (celeron J1900 4-core; 64x86, 2GB DDR3 RAM), not pi h/w.

The largest folder I’d encrypt/backup via duplicacy would be around 40gb (15,000 items). The server doesn’t do a lot, mainly syncs files real-time between other machines using syncthing. I’d run duplicacy operations at night. Would 2GB ram be enough?

Storj: is there a summary of pros/cons using native or s3?
Have around 70gb of data in total, of which a small fraction would change daily, for subsequent incremental backups.
Other larger files, i.e. music and video that don’t change much (around 750gb) I might as well use rysnc to backup?

As for security/privacy, my data is stored on a separate drive (from the OS) in the homeserver box. This data drive is LUKS encrypted (always needs manually inputted password at boot-up to become readable). So in theory, if attacker unplugged/stole the box, the data drive would be unreadable. My main concern is attacker being able to read files on data drive.

I’d be backing up folders stored on the luks drive.
Had a thought, aren’t Duplicacy config files stored at same location as the folder to backup? If so, then the plaintext passwords would also be effectively encrypted if the drive was stolen. The attacker trying to use duplicacy wouldn’t be able to access the folders. Or am I mis-understanding how duplicacy works?


To add: I can upgrade the memory up to 8gb if needed, on the homeserver