Unsolved
This post is more than 5 years old
6 Posts
0
1081
July 25th, 2017 12:00
symbolic links to f_cache2 files
Quick summary of environment:
We have 3 Linux Solaris host with multiple clients installed to allow for parallel backup jobs of mounted file systems (server1 with 4 clients, server2 with 8 clients, server3 with 4 clients).
Issue:
We noticed that each of the host servers' /var directory had a high percentage of used capacity (80 - 90%) and a majority of the usage was from the f_cache.dat files of each of the clients. Each host has 32 GB of memory so the default max file cache setting of -8 suggest to me that we should have a 4 GB cache file per client. However, what I learned was that with Demand-Paging in use, the f_cache2 file can expand as large as ~ 20 GB per client. This would exceed what our /var directory structure can hold since we have multiple clients on each host. I learned that we can move the cache files to a different location and then using either a symbolic/soft link or the --cachedir flag point from the original location to the new.
Questions
We are trying to avoid another FULL backup because our data sets have a very large file count and took multiple days to perform any full walk of the file tree. I understand a FULL being needed if we deleted or moved the cache files and used the attribute flag, but if I used a symbolic link instead could that avoid the need for a FULL walk. My thought was that since the avamar would still think it is writing to the same location, the FULL would be avoided and the data would just be passed to the new location in the back end by the host.
Am I way off base or does this seem like a valid hypothesis in need of testing?
ionthegeek
2 Intern
•
2K Posts
0
July 26th, 2017 05:00
As long as the client can read (and write) the cache in the expected location, you should not need to do another full.
dillon_menefee
6 Posts
0
July 26th, 2017 13:00
Thanks for the verification. I was getting mixed answers from support.
And I did test the theory as well.
1) Copy existing Dataset and modify options by adding vardir=/pathto/newlocation
2) Run backup to write new cache files to new location outside of default /var
2a) Monitor backup times
3) After initial backup completes, allow time for data to change and re run backup
3a) Monitor backup times
4) Copy cache files to 2nd new location, create soft-link to 2nd new location, and run backup for a 3rd time
4a) Monitor backup times
While second backup was running, I checked the moved cache file and say it being accessed and updated. That backup completed without issues.
Is there any advantage or use case where having each Dataset write and kept seperate its own cache makes sense or is required/advised? Since many of our datasets are specific per policy this would essentially create a cache per backup group.
And one last question: I copy the current cache files found in /var to a new multiple locations. Each location will be the location of the specific cache files for each dataset. Will the next backup still use the file as a reference and not require a full?
ionthegeek
2 Intern
•
2K Posts
0
July 28th, 2017 11:00
We used to do this occasionally for the older "monolithic" file cache for a variety of reasons (e.g. very large datasets). I doubt you would get any benefit from doing this with the paging cache since the paging cache addresses most of the use cases where we did this kind of cache splitting. You would also end up with several large cache files if you split the cache this way. I would advise against trying to use multiple p_cache2.dat files.
If you copied the cache file as you've described, it would be used for each job and wouldn't require a full but the caches would diverge from that point. You might run into complications if you made a large number of copies but that's probably not a great idea anyway.