[1500100900]

- "RAID is not a backup" primarily because "you could rm -rf". ZFS snapshots cover that failure mode to the same extent that synchronization with offsite does, but cheaper. ZFS snapshots obviously don't cover other failure modes like natural disasters or a break in, so RAID is still not a backup.

- for ZIL to do its work properly, you need the disks not to lie when they claim that the data has been truly saved. This can be tricky to check, so perhaps think about a UPS

- if you have two M.2 slots you could use them to mirror two partitions from two different disks for your data pool's SLOG. The same could be done to form a new mirrored ZFS pool for the OS. In my case I even prefer the performance that a single-copy SLOG gives me at the risk of losing the most recent data before it's moved from the SLOG to the pool.

[walrus01]

> - "RAID is not a backup" primarily because "you could rm -rf".

or your house could burn down

or somebody could steal the computer while you're away on vacation

or lightning could strike your electrical grid service entrance or a nearby pole/transformer, causing catastrophic damage

or your house could flood

lots of other things.. if you really have important data it's important to plan to for the total destruction of the storage media and server holding it.

[DarylZero]

> - "RAID is not a backup" primarily because "you could rm -rf". ZFS snapshots cover that failure mode to the same extent that synchronization with offsite does

Not really. You need to be synchronizing to a _write-only_ backup archive. A local ZFS snapshot can be deleted locally.

(Also fire, compromise, police confiscation, etc.)

[aqfamnzc]

> You need to be synchronizing to a _write-only_ backup archive.

For my write-only backup needs, this free service known as S4 works wonderfully:

http://www.supersimplestorageservice.com/

(This is a joke.)