search

borgbase / vorta

Desktop Backup Client for Borg Backup
https://vorta.borgbase.com
GNU General Public License v3.0
1.98k stars 130 forks source link

validating and repairing repositories #667

Closed Golddouble closed 3 years ago

Golddouble commented 3 years ago

What is best practice to run a "repository check"?

A) After each new "incremental" backup? B) Before we want to restore any backup? C) Before running the "thin out"-function (German "Ausdünnen") in Vorta "Archive Tab". (Edit) D) After running the "thin out"-function (German "Ausdünnen") in Vorta "Archive Tab". (Edit) E) Before we make a big change in our system, so that there will be a big difference between the latest snapshot. (Edit) F) other

For E): Maybe this way we would have a latest good chance for a "borg repair" in the case of any corruption.

Thank you.

samuel-w commented 3 years ago

Ideally, after each backup. There is no point in validating your backup before restoring it as if its corrupt then you have lost your data. If you check your backup while you have your original data if its corrupt then you can just create a brand new backup on a new device.

Golddouble commented 3 years ago

1)

If you check your backup while you have your original data if its corrupt then you can just create a brand new backup on a new device.

Not sure if I understand this part. Do you mean, A) I can just delete the latest snapshot and make a snapshot again? Or do you mean, in this case, B) I can make a new profile and a new repository and repeat the backup?

In case B) I will loose all my "incremetal snapsots".

2) in general: Does it mean, when the repository check was negative, I have lost all my snapshots?

samuel-w commented 3 years ago

See this Reddit comment, since Vorta uses BorgBackup as backend https://www.reddit.com/r/DataHoarder/comments/7h6k09/does_a_corrupt_sector_or_flipped_bit_in_a/

Golddouble commented 3 years ago

Thanks for the link.

If I understand this correctly, depending on the type of error, Borg sometimes allows you to fix errors inside a repository by starting a Borg repair.

If this does not help, there is a chance to take an additional snapshot in the same repository from the current original data. And then start the Borg repair again. If the original files are not too far away from the state in the repository, or parts are corrupted that are still present in the original data, these parts can be repaired in the repository.

In the discussion under your link, it was talked about making a repair.

Question: Does Vorta also offer this repair via the GUI? I have not found anything? Or do I have to use the terminal? (borg check --repair). (I did not have any corruption in my repository yet, but I want to be prepared for it, should it ever occur)

##########################################################

And I have extended the list from post "1". -> When should we perform a "repository check"?

A) After each new "incremental" backup? B) Before we want to restore any backup? C) Before running the "thin out"-function (German "Ausdünnen") in Vorta "Archive Tab". D) After running the "thin out"-function (German "Ausdünnen") in Vorta "Archive Tab". E) other

m3nu commented 3 years ago

Does Vorta also offer this repair via the GUI? I have not found anything? Or do I have to use the terminal?

Since much can go wrong and you should know what you're doing, better do this in the CLI. Vorta aims to cover common daily tasks in your backup flow. We will never cover 100% of Borg functionality.

Golddouble commented 3 years ago

Thank you for your statement.

Vorta aims to cover common daily tasks in your backup flow. We will never cover 100% of Borg functionality.

I understand this.

But I do not agree with the following:

Since much can go wrong and you should know what you're doing, better do this in the CLI.

Especially if one should need to know exactly what he is doing, a good and carefully developed step by step GUI assistant (e.g. in Vorta) can be a blessing. Especially for those who do not know what they are doing, but still want to carry out a repair. (Just my comment.)

samuel-w commented 3 years ago

Generally, you want to check your backups while you have your original data. so you can create a new backup in case the check fails. If you have an error, then it is safest to create a new full backup on another drive, since generally read errors/data corruption indicate a drive is close to failing. You will lose your incremental snapshots though, but its better than losing all your data. I've never had a bad check so far, but I've only been doing small 30ish GB backups.

Based on the documentation, borg check --repair recovers some, but not all of the data.

Sidenote: Seems like backup software in general have error detection, but no error correction.

Golddouble commented 3 years ago

Generally, you want to check your backups while you have your original data. so you can create a new backup in case the check fails.

My daily snapshot takes about 2 minutes. That's quite fast. When I then have to make a verify after each daily backup, this would take in addition 40 minutes. 42 minutes is much more than 2 minutes.

samuel-w commented 3 years ago

You can set the checks to be automated every few weeks or so. No need to do it after every backup, since data corruption is very rare.

The default of 3 weeks is fine for most cases.

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.