With many configs to save different parts of the local file system into different places in a backup system, it's difficult to know what's missing. I'd really like to know to be able to see files that have Not been configured somewhere in the set of config files.
For example:
Config stuff1 gets /stuff/good
Config stuff2 gets /stuff/bad
How do we know if there are other folders under stuff that aren't being saved?
If the stuff1 config has an exclusion for large files, how can we identify the large files so that we can create another config for them?
I know we can parse the .ffs_* files to derive our own solution for this. I'm wondering if it's already been done.
Thanks!
Brainstorming: What isn't saved?
- Posts: 25
- Joined: 2 Aug 2016
- Posts: 25
- Joined: 2 Aug 2016
An option: Create a new config for just /stuff that excludes */good and */bad. The Compare is all items on both sides that are different. While the obvious solution for many scenarios, it's more difficult if the target is not a 1-to-1 image of the source.
I've been using FFS for many years - not diligently but with occasional dedicated efforts to check and update the configs. I tend to organize the configs by category rather than by physical file system location. And over time source folders change. If we simply move a folder, the config that covers the new location will copy that folder in a new target location, not knowing that there is another folder with the same data - so now we have duplicates in the target.
And to the point of the original note here - if we copy a folder to a location that isn't covered by an existing config, how do we know?
Diligent and regular maintenance of the configs eliminates all of these issues. I'm just looking for a better policy for maintaining these specific configs. We can automate FFS and get some good use from macros, parsing logs, etc. Is there a resource where someone has already been documenting things like this or posting code that integrates with FFS?
I've been using FFS for many years - not diligently but with occasional dedicated efforts to check and update the configs. I tend to organize the configs by category rather than by physical file system location. And over time source folders change. If we simply move a folder, the config that covers the new location will copy that folder in a new target location, not knowing that there is another folder with the same data - so now we have duplicates in the target.
And to the point of the original note here - if we copy a folder to a location that isn't covered by an existing config, how do we know?
Diligent and regular maintenance of the configs eliminates all of these issues. I'm just looking for a better policy for maintaining these specific configs. We can automate FFS and get some good use from macros, parsing logs, etc. Is there a resource where someone has already been documenting things like this or posting code that integrates with FFS?
