Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zfs undelete (fast restore from snapshot) #16872

Open
shodanshok opened this issue Dec 14, 2024 · 2 comments
Open

zfs undelete (fast restore from snapshot) #16872

shodanshok opened this issue Dec 14, 2024 · 2 comments
Labels
Type: Feature Feature request or new feature

Comments

@shodanshok
Copy link
Contributor

Describe the feature would like to see added to OpenZFS

Currently, restoring a file from a snapshot means copying the entire file. This works very well most of the times, but it is a heavy operation for big files (ie: in the TB range). If the pool is short on space, restoring via simple copy is not possible at all (at least without using reflink).

Something as zfs undelete <snap>/<filename> would be very useful for such cases. After all data are already here, zfs should "only" restore the inode in the current directory.

How will this feature improve OpenZFS?

It would provide a very fast restore from snapshot.

Additional context

None.

@shodanshok shodanshok added the Type: Feature Feature request or new feature label Dec 14, 2024
@amotin
Copy link
Member

amotin commented Dec 15, 2024

Block cloning should be able to help with the copying right now without any additional work.

The undelete as requested could be possible only for the latest snapshot, since we can not edit ones created after the deletion, where the file was no longer existing. And even then it would be a bit of brain surgery. We would likely not be able to restore the inode/dnode, since it might already be reused or others sharing the same block could be modified. But the data and indirect blocks I guess could be restored indeed. Not sure it worth the efforts in presence of block cloning, but somebody may try. On a pro side it would be better from the point of replication, since block cloning is known to be not very friendly to replication.

@shodanshok
Copy link
Contributor Author

Sure, block cloning would help. However it is not enabled by default and, as you commented, it has some issues related to send/recv: cloning a big files not only means re-sending it entirely, but also receiving it (which can be impossible due to space limits).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature Feature request or new feature
Projects
None yet
Development

No branches or pull requests

2 participants