Starting to write down questions and things to do so that I can migrate from TrueNAS Core to vanilla FreeBSD for my home server.
I suspect that this will be easier than I think (thanks to ZFS), but it's very worrying, especially since I don't have a good way to back up 1.25 TB of data.
Guess I'll have to buy a new beefier external drive.
[#]freebsd #truenas #ixsystems
=> More informations about this toot | More toots from djfiander@code4lib.social
@djfiander I'm doing this actually and noting down my progress so far:
Who is this guide for? For purists who absolutely understand their system and want to maintain absolute control.
=> More informations about this toot | More toots from marzlberger@mastodon.online
@marzlberger Thanks for the info!
=> More informations about this toot | More toots from djfiander@code4lib.social
@djfiander you're welcome. I hope you enjoy the reading and it helps you a tiny bit. Feedback is always welcome. I'm far away from being perfect.
=> More informations about this toot | More toots from marzlberger@mastodon.online
@marzlberger @djfiander 1. Back up your data regardless of the OS
=> More informations about this toot | More toots from dexter@bsd.network
@dexter @marzlberger I did say it was time to get a beefier external drive.
=> More informations about this toot | More toots from djfiander@code4lib.social
@djfiander @marzlberger Indeed! Happy backing up! Note https://zelta.space/
=> More informations about this toot | More toots from dexter@bsd.network
@dexter @djfiander Oh, i didnt know that project, i will have a look. At the moment this project is on my list: https://github.com/psy0rz/zfs_autobackup
=> More informations about this toot | More toots from marzlberger@mastodon.online
@dexter @djfiander first look. Zelta misses the creation of snapshots on a scheduled regular base? The replication itself looks not too bad. i will play around with it definately.
=> More informations about this toot | More toots from marzlberger@mastodon.online
@marzlberger @djfiander Correct: Zelta leaves that to the user and goes to great lengths to 1. Not have dependencies on the destination and 2. Not force a deletion on the destination, a sin in the data protection world.
CC: @bellhyve
=> More informations about this toot | More toots from dexter@bsd.network
@dexter @marzlberger @djfiander @bellhyve 3. The destination should always call out to the system to do the backup and not the other way around in the event of compromise.
=> More informations about this toot | More toots from Tubsta@soc.feditime.com
@Tubsta I think it's probably better to create a per-system credential on each backup source, with limited scope so that it can push backups but not delete them. You can do this with, e.g., the restic REST server in append only mode, or in object stores like S3 that have granular enough permissions models. That way you don't end up with a single central point that's capable of getting into your entire estate and represents a particularly high value target etc.
=> More informations about this toot | More toots from jmc@unix.house
@jmc I agree when using object storage that doesn't have a smart head end. From a security perspective, prod should never be able to reach into backup under any circumstances. Backup can reach into prod using valid credentials to backup what is needed which means your backup are safe and a compromised host cannot interfere with them.
Object spaces, you'd use immutable storage but then you have other issues from a management/cost perspective.
Boils down to architecture really.
=> More informations about this toot | More toots from Tubsta@soc.feditime.com
@Tubsta I'm really not sure that giving the backup machine the authority to touch all production systems is a better architecture than giving each individual system a unique credential that only allows it to send (but not retrieve or delete) backups. I'm not sure what a "smart head end" is, either, but if it's just a UNIX machine you can run anything there, so running something that can accept backups without allowing the deletion of backups seems like an easy win.
=> More informations about this toot | More toots from jmc@unix.house
@jmc @Tubsta @dexter
FWIW, if the various machines are using ssh to connect to the backup machine, ssh's ForceCommand can limit to just the receive-a-backup command.
=> More informations about this toot | More toots from gumnos@bsd.cafe
@gumnos @Tubsta @dexter Yes! AuthorizedKeysCommand is also a good way to allow live integration with a management system of some kind.
=> More informations about this toot | More toots from jmc@unix.house
@dexter @djfiander Yes, to perforn an backup is one of the final articles and I will follow strictly the 3-2-1 approach. Samba will be next (im struggling how complicated I want to make it.
=> More informations about this toot | More toots from marzlberger@mastodon.online This content has been proxied by September (ba2dc).Proxy Information
text/gemini