grep is just a program that run on top of another text generating executable. It performs a search on strings/characters.@Apollo and @winnielinnie you both have guessed it correct.
I deleted the snaphsot 2024-03-01_00-00 ran scrub now its showing error on 2024-03-02_00-00. The problem is the data is of multiple files and I will be losing all the snapshots. Is there a way to delete specific items in the snapshot?
I have fixed the main file DOMINION_SQUARE1.db1 using the native application, but I need to figure out how to use grep on snapshots.
what you can do is something like that:
zfs diff ServerPool/MasterDataset/Projects@auto-2024-03-01_00-00 ServerPool/MasterDataset/Projects@auto-2024-03-02_00-00 | grep -i "DOMINION_SQUARE1.db1"
Can you provide more details on how you are using the data on this particular dataset? Are you copying file from PC to the dataset, or the data is always sourced from the dataset.
If the files are stored and modified on the dataset such as being accessed by a jail, then it may be impossible to recover the data after the corruption, because the problem could be compounded, unless the file is located in RAM and the corruption only occurred on the pool, but that is maybe wishthinking.
If we know your workflow, then we might come up with a better alternative which isn't going to rely on destroying your snapshots and the files it contains.
Some of the questions I have is about the current state of the files? At this point, we know there is corruption of some of the blocks. What is the state of the files located on the dataset?
If you know which the files on the dataset are corrupted and the one that are not, then you will be able to act accordingly. If the data is available elsewhere and you can replaced the corrupted ones, then deleting the snapshots after
shouldn't be too much of a problem.ServerPool/MasterDataset/Projects@auto-2024-03-01_00-00
However, if your files cannot be recovered and you want to mitigate disaster, then you can still delete the snapshot from
However, the files on the dataset would be most likely corrupted, unless if by magic the corruption occurred in a snapshot that reference part of a file which was overwritten by your application.ServerPool/MasterDataset/Projects@auto-2024-03-01_00-00
I see 2 approach to handling the replication issue and resolving the errors seen at scrub:
- Rollback to
and loose any changes since.ServerPool/MasterDataset/Projects@auto-2024-03-01_00-00
- Delete all failing snapshots after
which are pointing to corrupted blocks and then trying to manage restoring some of the files from you PC, but this could also leave some inconsistent states (ie database pointing at files which are no longer there...)ServerPool/MasterDataset/Projects@auto-2024-03-01_00-00
As I have stated, we need to know more about how those files are being used.
There is an alternative approach which you might consider which wouldn't involve destroying the snapshots and loosing the files it contains.
That would be to create "clones" of the snapshots and extract the files but that may not be too helpfool, unless you want to recover files before the corruption occurred, but the state of the files would be from the date when the snapshot was taken (if modification of the file did occur then).
I have this question: What do you know of the state of the files held in the dataset? The files in the dataset as seen by the jail, SMB... are live. If you can tell if corruption has occurred or not, it could prove useful. Yet again, it is specific to your use case.
If you were to take a snapshot now and delete all the snapshots in between taken after
Assuming the next one could beServerPool/MasterDataset/Projects@auto-2024-03-01_00-00
with a command similar to this one with the last snapshot taken after the one creted "now" above:ServerPool/MasterDataset/Projects@auto-2024-03-03_00-00
you could check if the error is still showing up. If no errors exist, then you would be out of the wood. However if error is still there, it would imply the error would still be pointing by the latest snapshot, but then again, zfs would be screaming with the live data, so I am not entirely sure.zfs destroy ServerPool/MasterDataset/Projects@auto-2024-03-01_00-00%auto-2024-03-015_00-00
What we really need to do here is to perform the
With snap1 and snap2 corresponding to the successive snapshots.zfs diff ... snap1 snap2 > diff_file.txt
such as:
zfs diff ServerPool/MasterDataset/Projects@auto-2024-03-01_00-00 ServerPool/MasterDataset/Projects@auto-2024-03-03_00-00 > diff_file.txt
zfs diff ServerPool/MasterDataset/Projects@auto-2024-03-01_00-00 ServerPool/MasterDataset/Projects@auto-2024-03-03_00-00 > diff_file.txt
zfs diff ServerPool/MasterDataset/Projects@auto-2024-03-01_00-00 ServerPool/MasterDataset/Projects@auto-2024-03-03_00-00 > diff_file.txt
And going through he file to see which files were modified.
You can also do the same with:
which should return any differences of the live data on the dataset since the time of the snapshot was taken ServerPool/MasterDataset/Projects@auto-2024-03-01_00-00.zfs diff ServerPool/MasterDataset/Projects@auto-2024-03-01_00-00 > diff_file_from_snap.txt
Files added and destroyed with this time frame will not show up.
I would say this could be enough to come up with our next strategy.
Last edited: