Several questions (keys, compression, speed) #7630
Replies: 6 comments 5 replies
-
|
Key Backup is critical as breaks of the system with the key would mean no more acces to the backup Restore from catastrophic failure is simply impossible without good backup of the key used for normal backup I'm unfamiliar with restic, based on their docs i would assume they errd on convenience instead of security and that assumption needs to be verified Borg is typically very io bound, even more so without compression |
Beta Was this translation helpful? Give feedback.
-
|
@RonnyPfannschmidt Thanks for the reply. I'm not sure what you mean by
Are you saying if the data is corrupted? If the data becomes corrupt, and the key is intact, you'll be able to access the repo but the repo will be corrupt and the key can't change that. If the key is corrupt, my question is, what could possibly corrupt the key that wouldn't also corrupt the data? In my eyes, the three elements here are the data, the key, and the passphrase. From what I understand, all three are as valuable as eachother. I don't see how backing up your keys are any more fruitful than backing up the data or passphrase, it's the same thing. The only factor in deciding which one you should create a copy of most would be if one of those three things have a greater chance at being corrupt or lost than any of the others. To me, it seems like creating two or more backups of the data, or creating another copy of the passphrase, would be more fruitful than creating a copy of the key. |
Beta Was this translation helpful? Give feedback.
-
|
Part of the security model is keys in different locations than the repo If the key is only available on the system doings the backup, then loss of the system implies loss of Access too the backup |
Beta Was this translation helpful? Give feedback.
-
|
It doesn't matter if the key is in a different location than the repo. Authentication and tampering aside (which I believe is the reason for having the key separate to the data, correct me if I'm wrong), whether you have a backup of that key in another location will not matter because you have a single point of failure; the data. You can have 10 backups of your keys but it will not change the fact that you only have one backup copy. I believe your assumed scenario is a situation where you are backing up data from one system to another, and you keep the key on the system doing the backup. Personally, I am backing up from one drive to another on the same system, so my use case is a little different, but my point remains the same; whether you store your key on a different location than the data or not makes no difference because you're simply creating an extra point of failure, you have to protect the key AND the data because they're in separate locations. Again, I don't see how this is better than having the key on the same location as the data, authentication and tampering aside. Since you never mentioned tampering, I don't think you're assuming that kind of threat in the critical failure scenario you're describing. Please let me know where I'm wrong here. Please don't misinterpret this as being combative, just putting my point across. |
Beta Was this translation helpful? Give feedback.
-
|
I'm getting the impression of intentionally misunderstanding, please refer to the documented threat Models |
Beta Was this translation helpful? Give feedback.
-
|
Well that's extremely rude of you. If I was intentionally misunderstanding why the hell would I make this post? I'm here to ask questions, not waste the time of yours and mine. I'm getting the impression that you simply don't understand what I'm saying. If anyone else is reading this, please note that I am still looking for answers despite what this person may believe. |
Beta Was this translation helpful? Give feedback.
-
|
Putting it differently;
Then it makes more sense to keep the key in the location of the backup since you have 1 less point of failure, OR place the key in the same location as your passphrase which is on a separate drive altogether, but I don't see how this is helpful because the key essentially becomes an extension of your password rather than a second factor. |
Beta Was this translation helpful? Give feedback.
-
|
@Opening-Button-8988 please calm down, ronny was just trying to be helpful and everything he said about borg was correct. for your consideration, i think it would help your understanding if you focus more - you were considering a lot of things that are maybe interesting and helpful otherwise, but not really needed for this discussion. also, maybe re-read what ronny said, maybe you were missing to fully understand it. about more focus:if one considers whether a backup of X is helpful:
X = borg keyIf the key is corrupted only one bit or if you lose the key, it is game over about using the related repository - you completely lost all backups in that repo. It does not really matter how or why it was corrupted (or lost), it also does not matter where you store the original key (repokey of keyfile mode). if you simply accept the possibility that this might happen somehow, it gets very clear that you want a backup of the key if you do not want to risk that. Resources needed: very little, the key is small. X = borg repositoryIf a borg repo is corrupted, one can try to repair it using If it is only a small issue, borg check can usually fix it with no or little data loss. Specifically, one bit of corruption does not imply total loss of the repository. Resources needed: a copy of a repo (or, better: another independent repo with same/similar contents) needs a lot of resources. |
Beta Was this translation helpful? Give feedback.
-
|
First of all, I have conducted myself perfectly calmly here. Secondly, I understood well what Ronny was saying, but I do not believe I was understood in return. What my question really boils down to is why is it recommended to backup your key?. The reasons I have been given are very simply not good reasons because they are not logically sound. I understand how vital the key is. But I don't understand why you would need to back it up if there's an equal or greater chance that your data or passphrase would become corrupt or lost. Having one copy of your data and passphrase but two copies of your key makes zero sense to me unless there's a reason why the key may become corrupt or lost but the data doesn't. How I see it is the key and passphrase both act like a username and a password. You need both to get in. Why would you save the username somewhere, but not also the password? And even if you have two copies of both, you still only have one set of data. You're only as strong as your weakest link. Please understand that I am making a genuine attempt to understand, and I'm taking a place of ignorance here. I genuinely don't know, and I genuinely want to know. But my questions haven't been answered. You both have made some attempts and I appreciate that, but I'm still looking for an answer. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I think I have given very good reasons for backing up the key. EOD Passphrase: of course you back up that also, that's pretty obvious and borg / the docs state that you should store a backup of both at a safe place. EOD Data: the docs also cover backing up to multiple repositories. So just have as many as you deem fit for your needs. EOD |
Beta Was this translation helpful? Give feedback.
-
Hello,
First off, I want to say this is a really great project and I think I've finally found my ideal backup solution (I use restic too). I've been looking for a backup tool that isn't crap for 6 years, most of that time spent simply not doing backups.
I have some questions. Please know that I have read the docs for both borg and restic, but I concede I only read what I thought was relevant to me and not with a fine-tooth comb, so please forgive my ignorance if I've missed something. I'm also fairly new to backup technologies.
Why is it recommended to save a backup of your keys? Isn't saving a backup of your keys redundant? It would make more sense to create a second backup with a different key. This requires more space, time and overhead, but a backup of your key is useless if the data itself becomes corrupted or the repository lost. I feel like saving a backup of the password would have greater value, since I think there's a greater chance of losing that. Under what situations would you need a backup of your key where data integrity is preserved?
Restic is very similar to Borg, and I don't remember reading in their docs recommendations to backup your keys. Assuming this is correct, does this mean restic is less reliable than borg because they don't support it, or they don't support it because it's redundant?
Under what circumstances should I compress backups? What kind of data and at what size is worth compressing?
When I run backups, uncompressed using typical config, I notice Borg doesn't use much CPU. Is there a way to increase the speed by giving borg more resources, or does borg go full throttle by default?
Beta Was this translation helpful? Give feedback.
All reactions