#ZFS was listed as experimental for #NetBSD 9. Per Wiki <https://wiki.netbsd.org/zfs/>, I would rather use FreeBSD which supports root on ZFS without the detour of FFS;
availability & support of Rust software as Python ecosystem seems to be using more of that as time goes by.
I personally need to check the situation in #FreeBSD with Intel CPUs with all E cores.
It is the "world #backup day", at least according to WorldBackupDay.com. I like the idea of having such a day, to serve as another nudge and a reminder to make and check backups, though WorldBackupDay.com is awkward, does not mention rsync in its software section. The "com" TLD looks suspicious, too, but it is better than nothing (except for potential private data leaks with online backup services).
I use primarily encrypted external HDDs (#ZFS or #LUKS with #ext4) and #rsync for personal backups, including rsync with "--dry-run --checksum" for scrubbing and checking before synchronization; quite happy that such tools are available, even though they are usually taken for granted, as are many other neat FLOSS tools we use regularly. Planning to add a USB stick to the list of storage devices, since it should be less fragile mechanically (even though less reliable otherwise).
Sharing some technical details about how I'm setting up the hosted email service. It will not be a service of BSD Cafe but tied to my own business. It will run entirely on BSD systems and on bare metal, NOT on "cloud" VPS. It will use FreeBSD jails or OpenBSD or NetBSD VMs (but on bhyve, on a leased server - I do not want user data to be stored on disks managed by others). The services (opensmtpd and rspamd, dovecot, redis, mysql, etc.) will run on separate jails/VMs, so compromising one service will NOT put the others at risk. Emails will be stored on encrypted ZFS datasets - so all emails are encrypted at rest - and only dovecot will have access to the mail datasets. I'm also considering the possibility of encrypting individual emails with the user's login password - but I still have to thoroughly test this. The setup will be fully redundant (double mx for SMTP, a domain for external IMAP access that will be managed through smart DNS - which will distribute the connections on the DNS side and, in case of a server down, will stop resolving its IP, sending all the connections to the other. Obviously, everything will be accessible in both ipv4 and ipv6 and in two different European countries, on two different providers. Synchronization will occur through dovecot's native sync (extremely stable and tested). All technical choices will be clearly explained - the goal of this service is to provide maximum transparency to users on how things will be handled.
This looks too good not to experiment with. You have interactive modes, can query for files and their restoration -- only thing that's missing for me a.t.m. is changing my Mac's APFS volume to ZFS 😞
Hey @ironicbadger, @popey, & other #ZFS#homelab users: what tools and processes do you use to back up your ZFS-based storage? Like most homelabers, I have a mix of file types and databases that I need to account for.
[#Linux#SelfHosting ]
This morning I decided to run some tests on bcachefs, which I hadn't tried out until today. Of course, I wouldn't trust it yet with important data. However, a couple of things impressed me: the background compression and the ability to use devices as cache. There's also the option to mix devices of different sizes, and reads will always be performed from the fastest device. If ZFS had these features, it would be wonderful.
My building has been having repeated powercuts for the last few days, and one today finally caused some damage to my #ZFS array.
The four unavailable disks are in the same caddy, and the error message looks very scary, but import -fF mounts the pool fine.
I'm not really sure what to do here other than running a scrub and looking seriously into investing in a UPS. If any ZFS nerds can help me out I'd be much obliged.
#rsync'ing a ~10GB #poudriere package directory /usr/local/poudriere/data/packages/foo elsewhere gets me a ~130GB target directory? What am I missing? #ZFS compression is turned on for both and compressratio is not really great, so that's not it. Using rsync -a, so nothing really special #FreeBSD
Two things I'd like to see added to #ZFS is, first an API for allowing programs to control trasactions on files, that is, "freeze" a file, allow arbitrary writes to the file, and then commit all the writes at once. This would allow DB's and others to not add their own logging layer.
After watching videos from @tomlawrence and @technotim about #TrueNAS I'm still somewhat undecided how to setup my 12-disk server with a mix of old/new disks for a general purpose storage (backup, iSCSI targets for VMs, etc...), but it seems like to have this kind of setup:
sdm: system disk (SATA DOM)
8 or 12 disks as 2-disk mirrors in a pool with NVMe for SLOG and maybe 2 or 4 SSDs for L2ARC, depending on whether I can fit them inside the 2 RU server or if I need to use drive bays for that.
@ij@tomlawrence@technotim lesser known fact: on #zfs, disabling sync writes with sync=disabled is more efficient than using a zil slog, if sync writes are not required, that is, loss of a couple of seconds worth of writes is acceptable.