With snapshots, do users need to worry about them overlapping if they fall into the same directories? Example is my main root-pool/dataset is a snapshot that is recursed, then underneath I have some apps being snapshotted at higher frequencies.
Are these creating extra space due to the overlap?
Very slow reply here Iâm also still a little confused.
Current Snapshots
MAIN/tank
MAIN/tank/tank-apps/app1
MAIN/tank/tank-apps/app2
MAIN/tank/tank-apps/app3
MAIN/tank/tank-apps/app4
MAIN/tank/tank-apps/app5
MAIN/tank/tank-apps/app6
My first snapshot of my entire tank dataset isnât set to recursive, but it snapshots everything from what I can tell on my windows shadow copies - in terms of directories.
When inside a folder, I right-click a blank area (many files/folders in directory) go to properties > previous versions, and it shows many historical snapshots.
If I were to set MAIN/tank to recursive, will it allow me to select individual files and then have previous versions available for them specifically?
Right now with my tank-apps snapshots, it seems like theyâre just redundant with the /MAIN/tank snapshot.
It took you one month to reply to your own thread?
Directories and datasets are two different things. Snapshots only involve datasets. If you happen to have folders that share the same name as child datasets, it can cause confusion.
When you browse one of those folders, what do you see inside? Where are you doing this? Under what SMB share?
It would act the same as if you had created multiple snapshot tasks, one for each child dataset. In the command-line, you would be able to browse and restore individual files and folders from each child dataset. The same would be true over SMB.
I still recommend you avoid naming folders the same as child datasets. You want to avoid mountpoint roots having the same name as folders (with files inside) of a filesystem higher up in the hierarchy.
Other than clutter and âpointlessâ snapshots, having a recursive snapshot task for Main/tank will not consume that much extra space, if any. If youâre happy with the individual snapshot tasks, then just use that. If you prefer the simplicity of a single recursive task. Use that.
You can create more granular requirements if you use individual snapshot tasks, rather than a single recursive task.
1.Inside my /MAIN/tank/ root directory SMB share or any sub-directories(not particularly sub-datasets)
2. I see all their files, I can select restore or open for any of the directories (not files)
3. Windows SMB share + Windows Previous Versions feature
My problem is that, I want individual files from all across my main tank dataset to have previous history available to it.
Right now it seems that if I want to revert a single file, I need to revert the entire directory it resides in.
Should be a way to get into the .zfs snapshot directory & then copy that specific file using CLI. Never done it but I imagine itâd go something like:
Edit: after a LOT of validation with ls to get the pathways correct, I successfully copied a single file from a snapshot to elsewhere. So this does indeed work - what tripped me up originally was that I was looking at my /mnt/pool/.zfs/snapshot instead of my /mnt/pool/dataset/.zfs/snapshot. Anyway, play around, it does work, but honestly âright clickâ âprevious versionâ was easier as I donât often navigate files through cli.
You need to clearly explain what your dataset layout looks like, what is being shared, and what share you are accessing from Windows.
All of this matters.
Datasets, even child datasets, might be confused for folders. This can cause confusion and weird behavior when accessing a âfolderâsâ previous versions in Windows Explorer.
Are you accessing the share of the root path /mnt/MAIN/tank via Windows Explorer? If so, then the âfoldersâ tank-apps and tank-apps/app1 are technically the root path for child datasets with their own snapshots.
What if you create an SMB share that points to /mnt/MAIN/tank/tank-apps/app1 and then access that with Windows Explorer?
You should also understand that if a file is not modified then there is no âprevious versionâ to restore.
If you want to restore a deleted file, you might as well navigate to the hidden snapshot directory, find the file, and then copy it over to its respective folder in the current writable share.
Something about this seems super over-complicated.
I understand what you guys are saying and CLI appears to give a much broader overhead to see whatâs actually being backed up, Iâm just finding the navigation of this all weird.
Is there some specific technical reasoning I canât recursively backup a whole tank Dataset, and itâs child datasets recursively, and be able access individual file changes in previous version?
Right now with a /mnt/MAIN/tank snapshot unrecursive, and a /mnt/MAIN/tank-apps/app1 recursive with empty snapshots, that has definitely had file changes in the last retention period, itâs not showing anything in my previous version historical data.
CLI it does inside of /mnt/MAIN/tank/tank-apps/app1/.zfs/snapshots/ dir, can see the file changes per snapshot of different timestamps.
Might be doing something wrong but no snapshot options with this method.
Maybe I explained how Iâm doing it on Windows poorly? I do right click the folder & go to âprevious versionsâ - then I double click one of the snapshoted version I want of the folder & it opens it with the previous file versions inside. I then copy/paste as necessary.
No youâre all good this works and you explained it fine, Iâm just having a bumpy day Also was just getting stuck on the fact I couldnât select single files when foldr previous versions work just fine with copy pasta