Move duplicacy cache out of root partition on linux

Support
#1

I installed duplicacy CLI on my ubuntu home server using \ as my repository (and filtering various branches out, of course). All works fine but I realized that the duplicacy cache folder is filling up my root partition (as the .duplicacy folder sits in \ by default). I’m not really a linux guy, so I’m asking here: what would be the best way to proceed (and how do I do it)?

To anyone reading this before initializing their root repository on linux: you best avoid this problem by [using the -pref-dir option of the init command:

(see also here).

I suppose there is a way for me to change the .duplicacy folder into a file, but I suspect this will be more complicated than moving the folder to a different partition and symlinking it from its original location (i.e. \), but how do I do this without breaking stuff?

#2

I believe you just need to create a text file .duplicacy in / with a single line that has the path to the actual .duplicacy directory (which doesn’t have to be named as such, either). e.g.:

mkdir /duplicacy
mv /.duplicacy /duplicacy/prefs
echo /duplicacy/prefs > .duplicacy

Though if you want to keep the root completely clear, you could use the -repository setting instead.

Already initialized, you’d need to edit the preferences file and change the line "repository": "", to "repository": "/", then move .duplicacy to wherever you want and run Duplicacy from there* instead of root. I guess it’d be a good idea to exclude this location with a filter, though(?).

(Normally you’d run this ‘repository’ configuration with the current working directory set outside, not inside, the repository - and this is the technique the Web Edition uses to keep repositories clean of any .duplicacy directories.)

Edit: *Some clarity - run from just outside .duplicacy (preferably an empty directory, with .duplicacy inside it), not inside .duplicacy.

1 Like
#3

If I don’t mind the .duplicay file in /, I can just follow the instructions below, right?

#4

Yup, that should do what you want.

I tested out the procedure recently, in trying to figure out the difference between -pref-dir and -repository during initialisation. I just tested it again and noticed something…

If you name the prefs directory anything other than .duplicacy, it gets included in the backup. So if your prefs dir resides within the repository (as it will if you backup from root), you might want to name it so, instead of prefs in my example.

1 Like
#5

Hm, shouldn’t it be something like

mv /.duplicacy/* /duplicacy/prefs

(because mv /.duplicacy /duplicacy/prefs will give me /duplicacy/prefs/.duplicacy as the relevant path, right?

Not sure if I misunderstood something but here is what I did:

root@server:~# mv /.duplicacy /srv/NAS/duplicacy/server/
root@server:~# ll /srv/NAS/duplicacy/server/
total 2
drwxrwxr-x 3 christoph christoph 3 jul 25 22:04 ./
drwxrwxr-x 3 christoph christoph 3 jul 25 22:03 ../
drwxr--r-- 3 root      root      6 jul 25 22:03 .duplicacy/
root@server:~# ll /srv/NAS/duplicacy/server/.duplicacy/
total 15
drwxr--r-- 3 root      root         6 jul 25 22:03 ./
drwxrwxr-x 3 christoph christoph    3 jul 25 22:04 ../
drwxr--r-- 3 root      root         3 dec 15  2018 cache/
-rw-r--r-- 1 root      root      1159 jul 23 00:58 filters
-rw-r--r-- 1 root      root       584 dec 17  2018 filters.save
-rw------- 1 root      root       486 dec 15  2018 preferences
root@server:~#

So I’m assuming that echo /srv/NAS/duplicacy/server/ > /.duplicacy wont do the job, right? So I did

root@server:~# cd /srv/NAS/duplicacy/server
root@server:/srv/NAS/duplicacy/server# mv /srv/NAS/duplicacy/server/.duplicacy/* /srv/NAS/duplicacy/server/
root@server:/srv/NAS/duplicacy/server# rm -r .duplicacy/

Will that work? Or did I mess things up?

#6

You can do it that way but my mv example intended to move the entire directory and not just the contents (which the /* would do). That original directory needed removing or deleting after, in order to create the file version of it.

Furthermore, you can rename the target directory in the same operation (.duplicacy became prefs).

Seems like what you have is /srv/NAS/duplicacy/server as your new preferences directory, so that is what you should have in your /.duplicacy file yes. (Although, as I suggested before, maybe rename to `server’ to ‘.duplicacy’, or place it inside a subfolder named as such, so it’s automatically filtered.)

#7

Also true, but the problem is that you then have the directory in the destination folder and I don’t see the point in having /duplicacy/prefs/.duplicacy rather than /duplicacy/prefs/ (or /duplicacy/.duplicacy for that matter). I also did not understand why the cache folder should be in prefs. But these are obviously just subjective preferences that don’t matter. I was just wondering whether I had missed something essential.

My strategy is slightly different: I think it does make sense to backup the preferences so I rather manually exclude the cache and logs subfolders.

@gchen, don’t you think duplicacy should automatically recognise its own cache files and refrain, by default, from backing these up?

One rather easy way of achieving this could be by activating the no backup file by default (i.e. giving the option a default value, e.g. .nobackup) and writing that filename into the cache folder by default.