Data in between ZFS snapshots

Status
Not open for further replies.

Dotty

Contributor
Joined
Dec 10, 2016
Messages
125
How you guys deal with this:
- Lets say I have automatic daily snapshots for 8 weeks, so 56 snapshots in total.
- I create a script that runs weekly and ship the last snapshot (Sunday) to another FreeNAS, and I keep them there for 1 year.

The question is: Someone creates a file on Monday, work on it, and delete it on Friday, so that file will be on the first FreeNAS, because of the daily Snapshot, but it will never make it to the second FreeNAS, correct?
What would be the best way to deal with this ensuring that the snapshots on the second FreeNAS has all the data that at some point was on the snapshots that were taken by the first?
 
Last edited by a moderator:

Ericloewe

Server Wrangler
Moderator
Joined
Feb 15, 2014
Messages
20,175
The best approximation is to have several schedules with different snapshot lifetimes. But that doesn't do what you want.

It's something you'd have to do with a script or something of the sort. ZFS snapshots can't handle that, and, by extension, neither can zfs send/recv.
 

nojohnny101

Wizard
Joined
Dec 3, 2015
Messages
1,478
Best I can think of is to increase frequency of the replication task. This could create a greater number of snapshots and more storage space used (depends on your usage of the replicated dataset), but seems to be the only way to accomplish what you want to do without some serious scripting (beyond my scope).
 

Robert Trevellyan

Pony Wrangler
Joined
May 16, 2014
Messages
3,778
It's a problem for any backup strategy, which can only be mitigated by increased backup frequency. Any data created and destroyed between backups is gone forever.
 

Dotty

Contributor
Joined
Dec 10, 2016
Messages
125
It's a problem for any backup strategy, which can only be mitigated by increased backup frequency. Any data created and destroyed between backups is gone forever.
Yes,, I guess I will have to sync daily to the second freeNAS then.
 
Status
Not open for further replies.
Top