Two clocks: why 30 and 7 means 37 days.
Because a B2 lifecycle rule runs two clocks in sequence, not one. The first, daysFromUploadingToHiding, hides a file that many days after it was uploaded. The second, daysFromHidingToDeleting, deletes the hidden version that many days after the hiding. Set 30 and 7 and a file is gone about 37 days after upload. No field on the form shows you the total, which is why people set what they think is a month and get five weeks.
One of four short guides to B2’s expensive surprises.
The two clocks, separately
Either clock can run alone. Hiding without deleting keeps a tidy current view while every old version stays stored and billed, indefinitely, which is the expensive misconfiguration in this whole area. Deleting without hiding removes old versions some days after they stop being the current one. Backblaze documents both settings, and the arithmetic between them is yours to do.
Source: Backblaze docs, lifecycle rules.
Why a file you deleted yesterday is still on your bill today is the other half of this behaviour, covered in the deleted files guide.
Prefixes, and what happens when rules overlap
A rule applies to file names beginning with its prefix. Where prefixes overlap, B2 evaluates every matching rule and applies the smallest value for each setting independently: not the first rule, and not the most specific one. A single delete-after-N-days control cannot express that, which is why a rule editor needs to show you the actual outcome rather than a summary of one clock.
Reading a rule before you save it
Bucketree gives each clock its own field and states the combined outcome in a sentence underneath the rule, before you save it. It also names the expensive mistake out loud: hiding files with no rule to delete them keeps every version stored and billed.
Thirty days free, then $25 a year.
Three Macs, or ten for a team, and no card to start. When the trial ends, browsing and downloading keep working.
