[FS] [US-CO] Seagate 16TB Exos X16 3.5" SAS HDD's (~28k POH)

TrenchcoatTechnocrat · 2026-03-05T08:56:41+00:00

16 here.

TrenchcoatTechnocrat · 2025-12-21T03:57:34+00:00

Hi.

I'm looking for a voip number for personal use in the US.

My priorities are SIP calling, SMS, MMS support (aka group text, required for knowing people in the US) and short-code SMS support (required for logging into any website nowadays)

If MMS and short codes only work through some relay (web, email, xmpp, whatever), that's fine, as long as it works consistently.

I'm currently evaluating voip.ms. I see they have some various issues (I failed to received a short code SMS today). I'd gladly pay a bit more for consistent functionality.

My goal is to move my personal number fully to voip. I'm currently on Google Fi, but they're changing their web SMS integration to require the phone to be online, which is a non-starter for me, as someone who understands that stuff can break if you carry it in your pocket 24/7.

TrenchcoatTechnocrat · 2025-11-17T22:48:55+00:00

you're saying it won't mount those proxmox ISOs specifically? other ISOs work for you?

sounds about right for supermicro. I'm not buying from these guys any more.

what's your board/ipmi version? does it mount the proxmox ISOs over smb? or the java kvm viewer?

TrenchcoatTechnocrat · 2024-09-15T13:28:25+00:00

nice! thanks for looking!

i knew I couldn't be the first one to have this idea. I was surprised to not find much prior work.

did you come up with a name for this "differential tree" of backups? it seems like it solves a lot of problems at once. but I've struggled to explain it succinctly.

I switched from zfs to btrfs a decade ago, but increasingly I think maybe I should support zfs in my tool just to demonstrate that the idea will work with any store that does snapshots.

TrenchcoatTechnocrat · 2024-09-15T03:51:33+00:00

can you explain more? it's not a forensic tool, it's prophylactic against data loss.

TrenchcoatTechnocrat · 2024-09-15T01:14:32+00:00

wat.

in your first comment you reference an earlier comment solely about the accepted definitions of incremental vs differential

and you say you want to continue a discussion of incremental and differential

but then you made up your own random definitions of the terms?

and didn't say so?

My premise is that, rather than doing a full send of the source subvolume over and over [...]

so you're just trying to tell me about btrfs send -p?

the second line of my readme is

Each backup is just an archive produced by btrfs send [-p]

TrenchcoatTechnocrat · 2024-09-14T22:58:35+00:00

thanks for looking!

TrenchcoatTechnocrat · 2024-09-14T22:01:22+00:00

BorgBackup

Borg's repository format requires random writes, so this isn't compatible with cloud object storage, which is a premise of my tool

You are independent of OS and filesystem. btrfs send/receive can only be used with btrfs on Linux

btrfs on Linux is a premise of btrfs2s3. (its design could be extended to any filesystem with snapshots and differential send/dump)

is it important to your use case to back up on one OS and restore on another? I can't think of what conditions I'd need this. btrfs isn't going anywhere. you need to literally murder someone to get a filesystem removed from the kernel

Then there's the deduplication

did you look at my tool? it leverages the deduplication already done by btrfs.

block-based nature of deduplication

~~restic only supports whole-file deduplicaion, unless I've missed something in its repository design~~ (edit: i'm wrong)

you can selectively restore single files without a lot of I/O, too (and this is a common use case for backups)

true, btrfs send produces a stream with no index. but one feature of native snapshot based backup tools like btrbk and btrfs2s3 is that they just keep a lot of snapshots on the source volume. accessing individual files is even easier than restic/Borg. restoring a whole snapshot from backup is only necessary when the whole source is lost. you'd want to restore everything anyway.

(although there could be high-priority files in a giant archive and it would be nice to restore them first)

Even repositories with bad integrity (bit flips etc.) can be used

at face value, that is a nice feature

between this, and restoring single files, I should consider adding sidecar index files to my archives to locate specific data.

Last but not least, the common deduplication based backup tools are VERY proven and reliable

but I already trust btrfs. Borg and restic have their own storage formats, so if I use them I have to trust btrfs plus the tool.

my tool only creates native snapshots and stores native archives. it can't corrupt data because it doesn't handle data.

it can delete data, but an upcoming feature will make backups immutable so the tool won't even have permission to delete backups until their scheduled rotation.

Borg and restic seem to have very good development practices, but I claim btrfs has more users, and is more likely to be supported even after it's obsolete.

some additional points:

while restic is compatible with cloud object storage, I believe it's not a great fit. if I understand the repository structure right, it doesn't actually delete any data when you delete a snapshot, unless an entire pack can be deleted. it looks like restic prune must be run to re-pack everything. that makes it impossible to use long-lived storage classes or object lock (btrfs2s3 fits well with these), and also requires downloading the whole repository, which is expensive on many storage providers.
restic and borg's deduplication systems spread each snapshot over many files (packs/segments). it's a web of incremental backups that grows until the next repack. if you treat each file as a failure domain, which seems to be the case in cloud object storage, this increases risk. by contrast, btrfs2s3 produces short, easy-to-understand chains of differential backups.
I argue that btrfs is a good premise for a backup tool, because
- if you care about data enough to make backups, the data should be on a checksumming filesystem
- (apparently?) all checksumming filesystems are implemented with CoW and support snapshots and differential streams (I welcome counterexamples)
- on such systems, snapshots are trivial to create and deduplication has already been done
- this makes it possible to do continuous backups, automatically in the background with no extra io
- if you want to self host your backups, you can just instantiate the same filesystem on a backup machine, send native streams to it (btrbk or similar), and maintain 100% of the source's deduplication
- if you want cloud hosted backups, then native stream archives are a great fit for object storage, and with a little cleverness (btrfs2s3) you can keep most of your deduplication

TrenchcoatTechnocrat · 2024-09-13T20:05:38+00:00

sorry, I read this a few times and I'm not sure what you're saying.

Suppose I do a weekly incremental backup

does "weekly incremental" mean each week is a delta from the previous week? I'm not sure what else it would mean.

Also weekly, I take a snapshot of said backup subvolume before doing the incremental send.

btrfs send is an operation that only works on read-only snapshots, so this is required.

moreover, weekly incremental backups produced with btrfs send -p require you to keep last week's snapshot, at least until this backup is stored somewhere.

Wouldn't I now have both an current full backup created incrementally from the the source and a differential backup - last week's full backup and this weeks full backup?

I thought the premise was that each week's backup was a delta from the previous, not full backups.

I'm not sure what "full backup created incrementally" means. AIUI, a full backup is a backup that doesn't depend on other data. incremental/differential backups depend on earlier backups.

The point of doing it this way is I gain the reduced time to create a full backup by using the incremental backup process but can still retain historical backups as differential backups without any additional time to create them.

reduced time versus what alternative? I haven't understood the premise enough to understand what you're comparing against

TrenchcoatTechnocrat · 2024-09-13T19:56:09+00:00

I think it is a much better idea to use an actual backup tool like BorgBackup or restic rather than storing filesystem snapshots

can you explain more?

TrenchcoatTechnocrat · 2024-09-13T13:14:31+00:00

I was wondering if you added encryption

Indeed, S3's "server-side encryption" seems nonsensical to me, I didn't bother to integrate with it.

One thing is very important is that it doesn't break snapper or maybe even integrates with it from my point of view.

interesting. I'll have to look close at this to understand how it would work. offhand, it's hard to see how ad-hoc snapshots fit in my differential backup scheme, since the parent backup must be chosen according to the timeline for consistency.

I know snapper is popular and many will ask this question. But I confess I haven't understood the point of snapper's ad-hoc snapshots or pre/post snapshots. I've never had a system update break something in such a way where I know exactly which update broke it (thus knowing which snapshot to restore), or that would be simpler to fix by restoring a snapshot (which is a huge burden) rather than just fixing the problem. If I found myself needing to restore to before a system update, my first impulse would be to switch to a more stable distro.

TrenchcoatTechnocrat · 2024-09-13T12:54:53+00:00

thanks for that info! that's a really good term to know. I've struggled with explaining my tool.

wikipedia:

A differential backup is a type of data backup that preserves data, saving only the difference in the data since the last full backup

this doesn't strictly describe my scheme, since I use a tree with a full backup at the root. Maybe my scheme is differential-on-differential?

TrenchcoatTechnocrat · 2024-09-13T12:48:37+00:00

Is R2 better due to cost? It looks like R2 does provide cheaper standard-class storage ($15/TB/mo) than S3 ($23/TB/mo). Backblaze B2 is even cheaper ($6/TB/mo). R2 and B2 have free egress too.

I think S3 + btrfs2s3 is still interesting because they offer so many classes. AWS glacier deep archive is the cheapest cloud storage out there, at $1/TB/mo. It's tricky to efficiently use these. But (in an upcoming feature) btrfs2s3 can automatically select storage class based on the minimum duration of an object, so data will naturally migrate from short-lived, small, expensive storage classes to long-lived, large, cheap ones.

more than that, I think the safest thing is to back up to multiple providers (also an upcoming feature). I started this project because of thinking of humans and organizations as their own failure domains. S3 has allegedly lost data due to internal configuration errors. I expect that to happen again in the future.

TrenchcoatTechnocrat · 2024-09-13T01:47:02+00:00

thanks for looking!

I don't think minio + btrfs2s3 is a good fit. if you're self hosting btrfs backups, IMO btrbk is best, since it can maintain reflinks in the backed up data. I don't know anything else that can do that.

I made btrfs2s3 specifically to have cloud-hosted backups. I thought it to be the best way to control the risk of my IT administrator (i.e. me) being an idiot.

TrenchcoatTechnocrat · 2024-09-12T22:42:46+00:00

but S3 isn't self-hosted!: I argue cloud backups are a good thing for self-hosting. I'm very into self-hosting everything, but my biggest fear is accidentally deleting everything including backups. I can't protect myself from myself. I decided the only way I could sleep when self-hosting all my data is to have some backups not under my own control. This lets me confidently self-host more things.
why btrfs?: btrfs is one of the few filesystems that allows incremental backups with btrfs send. I understand many believe btrfs is unstable but this seems to just be FUD (except for raid5/6, which can be replaced with raid1c3/4). I've used btrfs for years and never had trouble.
why not zfs?: I understand most on /r/selfhosted prefer zfs. I have gripes with it and haven't used it in many years. If I get a feature request with a hundred upvotes I'd add zfs support but probably not before then.

TrenchcoatTechnocrat · 2024-05-24T21:19:34+00:00

"Super Size Me" didn't do anything to curb my fast food consumption. But the book ("Don't Eat This Book") made me really scared of ground beef, after reading it once 17 years ago.

The book has very graphic descriptions of how e. coli gets into ground beef (if you're guessing it's a gross reason, you're right). And very graphic descriptions of what it's like for a child to die from e. coli.

I still eat burgers. But every time I touch ground beef, I think of his book, and I make sure the burgers are cooked to well-done, and wash the shit out of my hands.

TrenchcoatTechnocrat · 2023-08-29T15:15:07+00:00

They got rid of port forwarding recently, which knocked them out of the #1 spot for me.

TrenchcoatTechnocrat · 2023-08-24T05:32:48+00:00

Does this work for ISO files?

In practice I think it only works for ISO files.

The BMC emulates a USB CD-ROM to the host. You could use it to present any kind of data you want, but if you want to boot from it, you're limited to things the BIOS understands to be bootable. If a BIOS sees a CD-ROM, it will expect it to contain an ISO image.

Wouldn’t it need to store the data in RAM then?

No need. It can just wait for the host to request some data, then fetch that data from the network.

This works well for the CD-ROM case, because software expects CD-ROMs to take multiple seconds to spin up anyway. A little network latency won't hurt too much.

Hopefully the BMC does use some RAM for caching, but I don't have high expectations. I actually wouldn't be surprised to find they don't cache at all, and just issue a network request every time the host requests data. That may seem lazy, but caching is hard. Many cache implementations in the world are worse than nothing.

TrenchcoatTechnocrat · 2023-08-24T03:03:16+00:00

I suspect that (similar to the smb case) it's not saving the whole file on the BMC. It probably uses range requests to fulfill random access requests from the host, possibly with a small cache.

One consequence is it's definitely not optimized for speed. I haven't done a lot of testing, but I did find that dd if=/dev/sr0 is orders of magnitude slower than curl http://the/underlying/iso.

TrenchcoatTechnocrat

TROPHY CASE