107 karma · joined October 2, 2018
EBS limitations:
- Per-instance throughput caps
- Pay for full provisioned capacity whether filled or not
S3:
- Pay only for what you store
- No per-instance bandwidth limits as long as you have network optimized instanceNot only backup but also DR site recovery.
The workflow:
1. Server A (production): zpool on local NVMe/SSD/HD
2. Server B (same data center): another zpool backed by objbacker.io → remote object storage (Wasabi, S3, GCS)
3. zfs send from A to B - data lands in object storage
Key advantage: no continuously running cloud VM. You're just paying for object storage (cheap) not compute (expensive). Server B is in your own data center - it can be a VM too.
For DR, when you need the data in cloud: - Spin up a MayaNAS VM only when needed
- Import the objbacker-backed pool - data is already there
- Use it, then shut down the VMCrossmeta FUSE also includes sshfs, fuse-nfs for remote file access and s3backer to connect to any S3 compatible cloud storage.
All Crossmeta File systems fully visible to Windows Subsystem for Linux (WSL) but integration can be better with your help by voting on https://wpdev.uservoice.com/forums/266908-command-prompt-con...
Newer FUSE version 3 mostly address their limitations within Linux implementation. It adds support for concurrent writes and large transfer beyond 4KB. Crossmeta FUSE is look alike of Linux FUSE but the implementation does not inherit those limitations. It requires to do large concurrent transfer 128KB from Windows NT cache manager. I have to work the sshfs code to handle this since it was not exposed to such large transfer.
From FUSE it has support for sshfs and NFS client V3 and V4.
Crossmeta is just NOT about FUSE, it can also provide POSIX capabilities similar to Microsoft WSL. More here https://github.com/crossmeta/sys/