If you don’t use the "filters": key in the preferences file, will use the default filter file, which is unique per repository. Duplicacy has successfully backed up multiple terabytes of my most sensitive and irreplaceable data (family photos, mostly) to B2, and the data deduplication approach has cut the storage cost to a fraction of what it would be if I simply copied my data up to a B2 bucket via rsync or similar. Or, are filters like this the only option?Įdit: I should add that in all other aspects of my evaluation, Duplicacy is proving to be a fantastic and delightful tool, so I don’t mean to sound negative on it overall. Am I missing something, or is this pretty much the shape of it? Is there some secret method for coercing Duplicacy into following symbolic links that are encountered deeper into the repository than the root? I can’t find any mention in the documentation if so. duplicacy/filters file and reconcile those filter rules against the repository directory structure with meticulous care in order to ascertain the true nature of the files to be backed up. Under the new “correct” symlink structure, one must consult the. simply by browsing the directory structure of /backup). I was very optimistic about the original - but doomed to fail - symlink repository structure, particularly due to the ease with which I could survey exactly which files were going to be backed up (i.e. However! Even if those filters do work, I’m not sure I would be particularly thrilled with this setup. I haven’t tested it yet (because, frankly, I’m finding this a little frustrating), but I believe this set of filters should work, maybe? +boot/cmdline.txt duplicacy/filters file in order to curate my repository such that it matches my original plan. Obviously Duplicacy will follow these root-level symbolic links. So, with that in mind, I recreated my /backup directory as follows: /backup I’m curious about that "by default", but for now I’m just taking it as gospel that there is no way to get Duplicacy to follow symlinks that exist at any depth of the directory structure other than the root level of the repository. Symlinks located under any subdirectories of the repository will be backed up as symlinks and will not be followed. Move duplicacy folder/Use symlink repositoryīy default Duplicacy will follow the first-level symlinks (those under the root of the repository). From the documentation on symbolic links: When I run a duplicacy backup job on this repository, the etc files are the only files that get successfully captured in a revision. However, as I’m sure you all well know, this kind of mutli-level symlink structure does not work with Duplicacy. So, I ended up with the symlink structure you see in the tree above. The /var situation is even more complicated, because there’s a ton of stuff in there that I know I don’t care about, but there is also a pretty scattered collection of stuff that I do want. There is only one specific user home directory that I want to back up, so once again I created /backup/home and symlinked /home/pi in there. All of /etc can come (this is obviously not the greatest plan, but I didn’t feel like sifting through everything while I’m evaluating Duplicacy). There are only a couple of specific files I want out of /boot, so I created a directory at /backup/boot and symlinked those two files in there. │ └── shadow.bak -> /var/backups/shadow.bak │ ├── passwd.bak -> /var/backups/passwd.bak │ ├── gshadow.bak -> /var/backups/gshadow.bak │ ├── group.bak -> /var/backups/group.bak My first attempt at setting this up looked like this (please don’t make fun of my default rpi user haha): /backup I have a directory at /backup that I intend to be my symlink repository. Move duplicacy folder/Use symlink repository, Filters/Include exclude patterns, Improving the instructions for include/exclude patterns (filters)) and I think I understand, but I want to double check. I have read a number of topics and posts on this topic (e.g.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |