[OpenIndiana-discuss] set which fs do/don't get snaps besides timeslider

[Coalson, Timothy Scott (S&T-Student)]

Backups and snapshots are for different problems.  Backups are "insurance" for if the hardware fails or is damaged.  Snapshots are "insurance" for things like "wait, I deleted WHAT a week ago?".  Snapshots take almost no space or time for filesystems that don't have files deleted or overwritten often.  Backups take both space and time.

It sounded like your issues were with a GUI, and not with the existence of snapshots, so I'm not clear why you would specifically want to not have them.  I probably misunderstood your question.

Snapshots are not incremental, a zfs send is what can be incremental.  A non-incremental zfs send is a lot more data than needed if you already did a zfs send before (there is no communication from receive back to send, it can't tell it "skip that file, I have it already" - instead you can tell send to start at a snapshot, but receive must have that same exact snapshot already).

Our filesystem setup is simple (basically only one filesystem), but our backup with zfs send has the exact same snapshots the main filesystem does (such that you could receive a zfs send -i or -I at any of them), while if you start with rsync, you can never switch to incremental send without starting over from scratch.  Rsync needs to scan the entire directory tree every time, while incremental zfs send doesn't, so if you have a lot of folders with generally only small changes between backups, incremental zfs send is generally faster (and by using -I, all the in-between snapshots come over for "free").

Tim

________________________________
From: Harry Putnam <reader at newsguy.com>
Sent: Monday, November 30, 2020 9:07 PM
To: openindiana-discuss at openindiana.org <openindiana-discuss at openindiana.org>
Subject: Re: [OpenIndiana-discuss] set which fs do/don't get snaps besides timeslider

"Coalson, Timothy Scott (S&T-Student)" <tsc5yc at mst.edu> writes:

> You can tell time-slider to ignore a filesystem by:
>
> zfs set com.sun:auto-snapshot=false <filesystem>
>
> There are global settings for a custom time-slider schedule (number of
> each type of snapshot to keep, service auto-snapshot:<interval>,

> property "zfs/keep"), but I don't know of a per-fs one (though I
> haven't kept up to date).
Well of course there is setting the com.sun:auto-snapshot=[true/false]
If not present, add it.  You probably know about it too but just
starting to use it, I can see where it would be pretty tedious to keep
of with doing some regimen of snaps by cron.

> . . . . . . . . . . . . . . . .I actually wrote my own cron job that
> allows per-fs schedules and uses a bit different logic (but doesn't do
> recursive snapshots or track usage % of the pool), but the schedule
> specification is a bit arcane and not user-friendly.  The main reason
> I wrote it was so that I could have auto snapshots enabled during
> scheduled backups without complaints...

One method I used with software called `rsnapshot' on linux was cron
based and a fairly flexible script... relying on hard links to keep
down the backup size, probably something that could be adapted to zfs
snapshots.

It has a rolling deletion process based on a specific number of
hourly, daily, weekly, monthly that are kept till there turn comes to
be promoted of the end of the pier.

I figured I could slip in a few snaps if I wanted some to stay out of
the rotation just by naming someway the script does not expect or
rotate.

But this is all much more messing around than the trusty timeslider if
your setup is amenable to something that rigid.

Please tell me what you think of this:  I have certain zfs fs that will
be continually either refreshed to match the remote host they come
from with `zfs send -i (incremental)' or the trusty rsync set to
delete anything that isn't on the mother host.

I say either of those because I do not yet understand how incremental
snaps are supposed to work.  If that process is capable of refreshing
an existing fs to match the mother then I don't quite get why you need
to dink around with two snaps and not just be able to use the most
recent and merge that into the remote fs deleting what is not in the
snap and adding what is in the snap and not the fs or newer in the
snap than what is already there.  ala .. rsync.

But getting back to what I want your opinion on:

I'm sending data that copies the mothership to a remote host for
redundancy so it seems that since that data will be getting regularly
refreshed from the mother, then the need of snapshots is greatly
diminished if not obviated.

I'm asking if not snapsh'ing certain kinds of collections (matching
what I laid out above) would be a dumb way to proceed. Like is there
some other intrinsic safety factor that taking snaps would cover.


_______________________________________________
openindiana-discuss mailing list
openindiana-discuss at openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss