OK to have a snapshot lifetime of 1 year?

[SwisherSweet]

Since snapshots take up very little data, is there any issues to setting the snapshot lifetime to 1 year?

While I don't imagine I'd need to revert the file system to what it was 1 year ago, it would give me some comfort that I know that I could restore the dataset back to what it was one year ago if I accidentally deleted something important.

Assuming, I did revert the dataset to the state it was 1 year ago, can it easily be reverted back to current state once I get what I needed?

 

[rs225]

You should be fine, on all of that. Except rollback is a one-way street. In other cases, you want .zfs or clone, as others have explained better below.

edited: to correct that rollbacks can't be subsequently rolled forward.

 

[Stux]

Also you can clone the ancient snapshot too.

I've seen @jgreco post that he uses 10 year snapshots on his production server's document sets.

 

[SweetAndLow]

Just remember that any data you delete will not free up space until a year later.

 

[fracai]

I don't think that's accurate regarding rolling back. If you want to rollback to a previous snapshot, you have to destroy all snapshots after that point. You can't roll-back and then roll-forward.

Alternatively, you could clone a snapshot to a new dataset, or just grab files from the snapshot and bring them to the current dataset.

see: http://docs.oracle.com/cd/E19253-01/819-5461/gbcxk/index.html

# zfs rollback tank/home/ahrens@tuesday
cannot rollback to 'tank/home/ahrens@tuesday': more recent snapshots exist
use '-r' to force deletion of the following snapshots:
tank/home/ahrens@wednesday
tank/home/ahrens@thursday
# zfs rollback -r tank/home/ahrens@tuesday

 

[fracai]

Just wanted to add, you can easily pull files out of a snapshot by navigating the hidden ".zfs/snapshot" directory.

/mnt/<dataset>/.zfs/snapshot/<snapshot-name>/

 

[diedrichg]

Assuming, I did revert the dataset to the state it was 1 year ago, can it easily be reverted back to current state once I get what I needed?

As the others mentioned, you clone the snapshot which will create a new dataset with the files from that era. Once the data has been recovered, then you can destroy the clone.

 

[rs225]

I don't think that's accurate regarding rolling back. If you want to rollback to a previous snapshot, you have to destroy all snapshots after that point. You can't roll-back and then roll-forward.

Yes, you're right. I've edited to remove that part. I also use .zfs or clone, rather than rollback most times.

 

[Robert Trevellyan]

Since snapshots take up very little data, is there any issues to setting the snapshot lifetime to 1 year?

Snapshots take up essentially no space when initially created. They begin taking up space when the underlying dataset is modified. This means that after a year, a snapshot would be consuming space equivalent to all the changes made to the underlying dataset during that year (but no more than the size of the dataset at the time of snapshot creation). That might be an issue, or it might not, depending on the churn rate of your data.

 

[CraigD]

If you have a major problems the rollback feature is great

In Windows you can recover selected deleted files via SMB > properties > previous versions > open (I am sure you can do this on other OS's)

The means you can recover deleted files without changing files added since the snapshot was taken

Have Fun

 

[SwisherSweet]

Thank you all, the snapshot system is brilliant! :)

 

[diedrichg]

Oh! I don't think anyone mentioned it yet; DO NOT snapshot the parent of your datasets (top level of the pool), only snapshot the datasets because the snapshot system is recursive.

 

[fracai]

Oh! I don't think anyone mentioned it yet; DO NOT snapshot the parent of your datasets (top level of the pool), only snapshot the datasets because the snapshot system is recursive.

What's the problem with snapshotting the top of the pool? I have a single recursive snapshot task that handles every dataset. I've never had a problem. Am I misunderstanding you here?

 

[SweetAndLow]

What's the problem with snapshotting the top of the pool? I have a single recursive snapshot task that handles every dataset. I've never had a problem. Am I misunderstanding you here?

I snapshot my root also. It's the simplest way to do it.

Sent from my Nexus 5X using Tapatalk

 

[diedrichg]

What's the problem with snapshotting the top of the pool? I have a single recursive snapshot task that handles every dataset. I've never had a problem. Am I misunderstanding you here?

But, I thought that would then cause you to have to have all datasets cloned during a recovery? I must be thinking of something else then...

 

[SweetAndLow]

But, I thought that would then cause you to have to have all datasets cloned during a recovery? I must be thinking of something else then...

Nope, snapshots are specific to the dataset and you only have to clone a single dataset snapshot.

Sent from my Nexus 5X using Tapatalk

 

[Stux]

I snapshot my root for a couple of weeks. Various other datasets then have longer retention policies

 

[diedrichg]

I just remembered wth I was thinking earlier. Don't setup a share pointing to the top level of your pool.

 

[fracai]

The way that I have an AFP share pointing to the root of my pool?
What's the caution there?

 

[SweetAndLow]

I just remembered wth I was thinking earlier. Don't setup a share pointing to the top level of your pool.

This is a great best practice. If using jails people who setup a root share will destroy their jails permissions on accident. Splitting up your data is good idea so it can be snapshots differently or backed up on a different schedule.

Sent from my Nexus 5X using Tapatalk