What happens when the quota size is reached?

[ddofborg]

I cannot find any information on what happens when the quota size on the repo is reached while backing up? Or when the free space runs out.

Can anyone shine some light on this (and maybe add something about this to the docs, borg init and borg create maybe)?

Also it would be nice if borg create would get some options to control what happens when quota is reached. Like prunning older backups with some --keep-XXX actions OR raising an error?

[ThomasWaldmann]

IIRC it will just abort in the middle of the backup that exceeds the quota / free space.

There is no automated resolution of that "full" state and I also would rather dislike making that built-in into borg create, making the command's code and command line interface even more complex than it already is (especially not by mixing in functionality for which we already have a separate borg prune command).

You can just use borg prunewith reasonable values to make your repo space not overflow usually.

Also you must use some kind of monitoring anyway to make sure your backups actually work and if monitoring shows failed backups you can decide how to resolve that (usually it is by adjusting prune parameters, excluding some unintended stuff from the backup source or increasing quota / available space for the repo).

[ddofborg]

I do agree this would make things more complex, but I don't think current abort method is the best user experience. Especially not with such an amazing tool as borg.

Having a way to example remove oldest backups first would be very useful.

From what I see there is no way to do a dry-run and see if the backup would fit. That could be a less complex solution; basically do dry-run before actually uploading the backup. If it fits, then just upload the files? If it fails, remove the oldest backup (or N oldest backups with total size of amount of needed space), then run the backup. If that fails, then abort. Or if backup is larger than total quota, abort too.

What do you think about this feature?

[ThomasWaldmann]

Even "oldest" is not simply defined nor is it clear whether that is what the user wants. See borg prune options and how they must be used, esp. if one backs up multiple data sets into same repo.

Yes, due to dedup, there is no simple way to determine whether something fits. And it also doesn't make sense to make some "advanced dry-run" if that would take a similar effort as really doing a backup.

Also due to dedup, it is not easy to see how much space is freed by removing N backups for N>1.

A relatively simple thing we could do is have more distinct error codes / return codes (see other ticket about that) instead of just 0/1/2. Then some borg wrapper (e.g. your backup script) could detect the "out of quota / disk full" and invoke borg prune / borg delete and do whatever you want.

[ddofborg]

There is an issue with quota (out of space) which is not addressed well. And I believe there is a solution which is not too hard for a use-case which is common enough.

Let's think and discuss here what is possible and how is can be done and not what is not possible.

Even "oldest" is not simply defined nor is it clear whether that is what the user wants. That was just given as an example. Other options can be added if user wants something else.

I think you can find the first backup and keep everything just after that date. If the oldest backup was created 10 days ago (created daily), then you can keep everything 9 days old or less. That should remove the oldest backup. Or am I missing something? Basically borg prune --keep-within <now - first_backup + 1 second>s.

Yes, due to dedup, there is no simple way to determine whether something fits.

How so? borg create knows wether a file needs putting or not. So you do a dry run and sum up all put files/chunks. Then you know the size of the new backup which will be added to the repo. If it fits, great, put the chunks. If not, delete oldest (or other algorithms) first and see if that fits, it not, delete another.

If you run borg info --first N REPO you can see the extra size of each archive (if I understand this archive row correctly) and I think this would be the space you would free up is that is pruned. So you can start at the end (first archive) and prune your way up to the newest archives until the free space is there.

All this is possible with some scripts, I am sure (especially because of the --json option). But a more elegant solution within borg itself would be a much better option. Especially because most functionality is already present.

And it also doesn't make sense to make some "advanced dry-run" if that would take a similar effort as really doing a backup.

Maybe in your case it does not, but in my case it does. I'd rather have a full backup of something from yesterday, than a full backup of something from last year.

[ThomasWaldmann]

you'ld need to sum up compressed deduplicated chunks. that's a lot of effort to just determine a number, not much less compared to just trying to create the real backup and then you'll see if it fits also.

you can't just sum up the deduped sizes of single archives to get the deduped size of them all. the number you get is likely too high as they also dedupe against each other.

[hexagonrecursion]

The plan:

1. borg create should print something green if it is successful and something red otherwise.
2. A new documentation section named "Troubleshooting" should be created. All entries that deal with errors and other undesirable conditions should be moved from the FAQ to "Troubleshooting". I think this is more intuitive and therefore less stressful for a potentially already stressed user. Currently this information is scattered throughout the FAQ.
3. Two more entries should be added to "Troubleshooting": "Help, I ran out of repository quota!" and "Help, I ran out of space on my filesystem!"
4. borg create should print the URL of the relevant troubleshooting page when quota or free space runs out. Ideally the contingency should refer the user to both a URL and a borg help topic:
   • A URL alone is useless if the internet is down
   • It can not be ruled out that the issue that broke borg create also breaks borg help.
5. The documentation for borg create should advice manual users to check the output and automated users to monitor the exit code. It is important to remind the users that a backup can fail for 1000 different reasons and that allowing the errors to go ignored is a bad idea.

[ThomasWaldmann]

1. borg does not use coloured output and that should stay like that for now.

2. i agree about faq and troubleshooting split (although there is some potential issue with deciding where to put something).

3. ok

4. iirc, borg does not print URLs yet and i'm not sure we should start doing that.

5. automated users might have to check both rc and output, depending on how much automation is desired. also, there is --show-rc to make the rc visible in the output.

[ThomasWaldmann]

and most of the stuff discussed in the last 2 posts is off-topic in this ticket and should be in a separate ticket.

[hexagonrecursion]

most of the stuff discussed in the last 2 posts is off-topic in this ticket

Ok. Are the following on-topic?

• 3 Two new FAQ topics
• 4 borg create advises the user to run borg help no-quota or borg help no-space when relevant
• 5 The docs for borg create remind users about the minimum required monitoring

[ThomasWaldmann]

Sounds good, would use no-quota-left and no-space-left (or filesystem-full) as id.

[fantasya-pbem]

4 borg create advising the user to borg help <id> would require changes in the code to detect the right case, or at least to print the right advise, wouldn't it? So that is not just a documentation issue, but also enhancement I guess. We should cut out this into its own issue then, too, and add the docs for 5 as we improve the create command anyway.

What remains is 3, two new FAQs.

Are you d'accord?

[ThomasWaldmann]

sounds good.

[fantasya-pbem]

I have created a PR for the two FAQs and will backport them to 1.2_maint when approved.

As a follow-up to this issue I offer to make another PR that introduces the "Troubleshooting" docs.