Re: LTO support

[David Brownlee <abs%absd.org@localhost>]

On Thu, 12 Aug 2021 at 08:11, Pouya Tafti <pouya+lists.netbsd%nohup.io@localhost> wrote:
>
> I'm looking for a low cost offsite backup solution for my teeny local NAS (couple of TiB of redundant ZFS RAIDZ2 on /amd64 9.2_STABLE) for disaster recovery.  Seemingly affordable LTO-5 drives (~EUR 250; sans libraries) pop up on eBay from time to time, and I thought I might start mailing tape backups to friends and family.  Being rather clueless about tape, I was wondering:
>
> - is using an LTO drive for manual backups (or backups at this tiny scale) a fundamentally dumb idea?
>
> - how well-supported and widely-used are they on NetBSD (wrt both kernel devices and userland tools)?
>
> - are there reliable strategies to split a larger ZFS volume across several smaller cartridges (LTFS seems not to support splits)?
>
> - are there specific caveats to watch out for (e.g. if used drives are to be avoided, or would end up being cost blackholes necessitating further equipment, obsolete media, etc.)?

Another couple of possible options (Not saying "don't use tapes", but
for reference)
1) Backup to external disks (either in USB case or just bare disks
hooked up to adaptor) - depending on how they are formatted they can
be "drop in" replacements for your active data, so no waiting for
tapes to restore
2) Offsite NAS with a copy of the data

With the caveat that a remote online copy of the data is _not_ a full
backup (any nefarious individual who gains online access to both, a
software bug, or operator can wipe everything), the offsite copy does
have a number of convenience & feature advantages:
- Data can be complete & "ready to go", including for catastrophic
failure which takes out all original hardware
- Choice of levels of redundancy on remote copies, from RAIDZ2 to none
- Freshness can be from close to realtime (active sync) to well
defined period (nightly backup)
- Can run full backup software, including incrementals,  ~live sync
(which can also include options to keep deleted/previous revisions),
or zfs snaphots & cloning

An example would be a main RAIDZ2 system backed up to two smaller
remote systems with non redundant ZFS filesystems using syncthing with
staggered file versioning
https://docs.syncthing.net/users/versioning.html to keep previous
versions (Note: there is an issue with syncthing on NetBSD where
"Watch for changes" has to be disabled for reasonable size
collections, relying on periodic rescans). The main system is set to
send only, the two remote to send/receive so they can sync changes
from each other. OpenVPN is also thrown into the mix to allow easy
remote access to a system behind an "external traffic only" firewall.

All data is still at risk from any of:
- Security vulnerability affecting all systems (and exploited on all systems)
- Misconfiguration/operator error (would be an impressive one to hit
all three, but possible)
- Catastrophic syncthing bug

But I'm happy with the risk/benefit tradeoff in this case

Occasional read-only access to the data at the two remote locations
was required, and the original setup was pre migration to ZFS, which
constrained the original choices. When NetBSD gains native ZFS
encryption I may look again at ZFS snapshots and possibly
https://zfs.rent/ or https://www.rsync.net/products/zfsintro.html :)

David