Automatic snapshots / Pruning/How to find/recover files (Possible Feature Request)?

Status
Not open for further replies.

NASbox

Guru
Joined
May 8, 2012
Messages
650
Not sure if this is the right place to post this, but this is both a "possible suggestion" and questions (in bold).

I use FreeNAS in a SOHO environment where the system can sit for hours (and sometimes days) without any significant data changes and changes don't follow a regular schedule.

I like the idea of an automatic snapshot every 10-15 minutes when I'm working, but this will quickly make the list of snapshots very unwieldy.
It's getting hard enough to find things now--pretty much given up on the GUI and just grep from the shell.

I was thinking about doing something like the following with cron, and wondered if it might be a useful option to add to the automatic snapshots.

After automatic snapshot:
zfs diff POOL@previous-automatic POOL@new-automatic
if NO CHANGES
zfs destroy POOL@previous-automatic

How "expensive" would this be? Is the cost based on the size of the "POOL" or the "delta"?

Is there any way to quickly check for "delta" != None -- any change at all is enough to not delete the snapshot, no sense wasting resources enumerating changes just to discard them.


I think home and small business users would really benefit since there would likely be less snapshots to search through if it was necessary to go back and recover a file.
Instead of saving 8 hours of 15 minute snapshots with 60% of them empty, saving the last 32 changes would provide better data security.

Consider the following timeline... automatic snapshots being taken

FILE [WORKING] - SNAP001 <-last kept snapshot-contains an old working copy
.
. changes to FILE in snapshots SNAP015, SNAP025, SNAP067, SNAP105, SNAP115
.
FILE [GOOD] - SNAP127 <-Project saved .. last good copy
.
. no changes to FILE
.
FILE [GOOD] - SNAP149 <-Snapshot still has a good copy.
FILE [CORRUPT] - SNAP150 <-Human error - file messed up somehow but not noticed
.
. no changes to FILE
.
FILE [CORRUPT] - SNAP210 <- The "Error" is discovered

Is there any easy way to quickly find SNAP127 or SNAP149 that contains the file before the "bad" changes were made?
Note that when attempting to find the last good copy, assume no knowledge of when the error occurred, or if a good copy exists/still exists.
Manually searching 60 snapshots is going to be a chore.
Another possible solution would be a script that listed all changes to file FILE. i.e.
findchanges FILE
Output: SNAP015, SNAP025, SNAP067, SNAP105, SNAP115, SNAP127

I'm sure I'm not the first person to have to deal with this, so I'm hoping somebody has some ideas.
I don't expect a "solution", but hints/how to proceed/research. Thanks in advance.
 
D

dlavigne

Guest
How are you sharing the files? SMB Previous Versions will display the versions for you, for each file.
 

PhilipS

Contributor
Joined
May 10, 2016
Messages
179
Previous versions works well for me and my users. You need to pick the snapshot schedule for you share in your SMB sharing settings for it to work.

If you don't want a bunch of empty snapshots, someone wrote a script that will prune them out, it's the clearempty.py script. You can schedule it to run through cron in the GUI.

https://github.com/fracai/zfs-rollup
 
Status
Not open for further replies.
Top