Hacker News Reader

Comment by inglor | Hacker News Reader

As a contrast to your take - I work for a backup company and I was really surprised to discover most of our customers (big enterprises) really do not care about 99% of metadata restored correctly and are fine with just restoring the data.

(We restore everything super carefully but sometimes I feel like we're the only ones who care)

View on HN

I'm willing to bet a decent number "don't care" until they do care because their permissions don't work or their time based script screws up or whatever else nobody thinks about when they're in panic mode about "I lost my data".

In case of a complete disaster recovery, the fact that a script or two might fail is super OK. That's why after recovery there's always the cleanup phase where you fix stuff that broke during recovery.

They don't care because you care, so they never experienced the misfortune of not caring.

Nah. Not really. A lot of the useful data out there doesn't need ACL, precise (or any dates at all) etc.

Also, a lot of application-specific data formats already don't care about the "extra" attributes available in various filesystems because those aren't universally supported and implement them themselves in the file format they operate on. For example, DICOMs, or password-protected PDFs or Zip archives etc.

Extended attributes (and resource forks) are mostly a liability and anti-pattern because of their non portability. It would be a huge red flag to find something important in there other than cases of backing up entire OS images.

I too have worked at a back company and I can’t recall any of the customers caring or even knowing about the metadata.

We would only care if the software our customers were running did. Big enterprise software suits were defined to run in hostile environments, in such they mostly rely on their data formats and don’t care about attributes from the filesystem other than so they have access.

I'm with you on this, I think that data is 99% of what is important and the rest can be recreated or improvised and if in your system you rely too much on file metadata your need more engineering

If that information drives operational processes then you can argue it is data, not metadata.

The output of the command the OP mentions

  $ /usr/bin/rsync –version

...doesn't return anything referencing openrsync. I'm on Sequoia 15.3.1.

The change was made in 15.4

ugh. these kind of changes should not be made in a minor release..

Is it a breaking change?

Missing sarcasm tag?

> in your system you rely too much on file metadata your need more engineering

Except sometimes it's a 3rd party's app whose data you have to restore, and you don't have control over their engineers.

That's the kind of nonsense thinking that leads to folks like apple removing critical features that "noone uses".

reminds me of that yogi berra quote "nobody goes there anymore, it's too crowded"

For example, many people don't even understand target disk mode on apple hardware, but it has saved me countless hours over the years and made administering apple systems a breeze. Ask people who've used target display mode if they can imagine going without it.

on another subject - it's worth mentioning that time machine is based on rsync.

Apple is the wrong horse to back on for this sort of thing.

Reply on news.ycombinator.com