Comment by gilrain
3 days ago
> You are using it to mean "maintaining full version history", I believe?
No, they are using it to mean “backed up”. Like, “if this data gets deleted or is in any way lost locally, it’s still backed remotely (even years later, when finally needed)”.
I’m astonished so many people here don’t know what a backup is! No wonder it’s easy for Backblaze to play them for fools.
But isn't that exactly what Dropbox does? If I delete a file on my PC, I can go to Dropbox.com and restore it, to some period in the past (I think it depends on what you pay for). In fact, I can see every version that's changed during the retention period and choose which version to restore.
Maintaining version history out to a set retention period is a backup...no?
definition of the term backup by most sources is one the line of:
> a copy of information held on a computer that is stored separately from the computer
there is nothing about _any_ versioning, or duration requirements or similar
To use your own words, I fear its you who doesn't know what a backup is and assume a lot other additional (often preferable(1)) things are part of that term.
Which is a common problem, not just for the term backup.
There is a reason lawyers define technical terms in a for this contract specific precise way when making contracts.
Or just requirements engineering. Failing there and you might end up having a backup of all your companies important data in a way susceptible to encrypting your files ransomware or similar.
---
(1): What often is preferable is also sometimes the think you really don't want. Like sometimes keeping data around too long is outright illegal. Sometimes that also applies to older versions only. And sometimes just some short term backups are more then enough for you use case. The point here is the term backup can't mean what you are imply it does because a lot of existing use cases are incompatible with it.
> To use your own words, I fear its you who doesn't know what a backup is
Feel free to use my reputation, instead: when I say a system is backed up, data cannot be lost by that system being destroyed, because an independent copy always exists. This satisfies those whom it concerns, who put their money where their mouth is, whereas your more generous but insufficient definition would absolutely not be good enough.
When you assure a client that a system is backed up, which definition do they expect from you?
> When you assure a client that a system is backed up, which definition do they expect from you?
the one in the contract (and the various EU laws)
that is not a satisfying answer, I know
e.g. in some past projects the customers explicitly did _not_ want year long backups and outright forbid them, redundant storage systems + daily backups kept for ~1-2 weeks (I don't remember) had been pretty close to the legal limit of what we are allowed to have for that project (1)
the point I'm making was never that a good general purpose backup solutions shouldn't have versioning and years of backups
it's that
1. the word backup just doesn't mean much, so you have to be very explicit about what is needed, and sometimes that is the opposite of the "generic best solution"
2. If data is explicitly handled by another backup solution, even if it's a very bad one, it's understandable that the default is not to handle it yourself. (Through only the default, you should always have an overwrite option, be warned if defaults change, etc.).
Insisting a word means something it doesn't in a way where most non-tech people tend to use it in the definition you say isn't right just isn't helpful at all. Telling them that this is a very bad form of backup which they probably shouldn't use is much more likely to be taken serious.
---
(1): Side note: It's because all data we had is backed up else where, by a different solution, and sometimes can be a bit sensitive. So the customers preferred data loss (on our side, not on theirs) over any data being kept longer then needed (and as such there being more data at any point of time if there is some hacker succeeding or similar). And from what I have heard that project is still around working the same way.
But ironically that is similar to the case here, the data is owned/handled by a different system and as such we should not handle the backup.