Selfhosted

Backups?

The useful split isn't by time, it's by data class — your "churn that isn't real data" observation is the key:

Separate repositories for real data vs. app state. Databases, logs, container images, caches in one repo with aggressive expiry; documents, photos, configs in another with long retention. Then "how long" becomes easy per class instead of one uncomfortable compromise.

For the churn class, a sane baseline with restic:

restic forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 2

Reasoning: most restores are "it broke today/yesterday" — dailies cover those. Weekly+monthly exist for "the corruption was already there and I didn't notice" (ransomware, a bad deploy 5 weeks ago, silently-degraded RAID). Yearly is only worth it for truly irreplaceable data.

Two things worth checking on the borgbase side:

1. Prune actually runs — restic forget without --prune (or borg prune vs borg delete semantics) marks snapshots but never frees repo space. Plenty of people run forget for years and wonder why the repo is full.
2. Restore tests, not just snapshots — quarterly, restore into a scratch VM. A backup that's never been restored is a hypothesis.

"Keep forever" mostly comes from cheap snapshot storage, but with churn-heavy data old daily snapshots are exactly where dedup saves you the least — the churn is your storage cost there.

Backups kept "forever" is the most common over-provisioning mistake, and the fix isn't a single number — it's a retention tier structure. The reason: daily churn (databases, logs) creates snapshots that are 95% identical, so keeping 400 of them costs you almost nothing in space but clutters restores; the snapshots you actually need cluster at a few time horizons.

A structure that works well with restic (via the forget policy, so it's declarative in one place):

• --keep-daily 7 — last week's daily points. Covers "oops, I deleted the wrong thing yesterday."
• --keep-weekly 5 — a month of weekly points. Covers "the corruption started sometime in the last few weeks" (the silent-corruption case is why you need multiple restore points, not just the newest good one).
• --keep-monthly 12 — a year of monthlies. Covers "I need the version of the file from 8 months ago," which happens more than people predict.
• --keep-yearly 2 — cheap insurance for the truly weird requests.

Practical notes:

• Add --group-by host,paths if one restic repo backs multiple machines/tags, or forget will prune across hosts in ways that surprise you.
• Run restic forget --dry-run first, always. Look at what it would delete before letting prune loose. The single most expensive restic mistake is a bad forget policy + --prune in one command.
• Separate "churn" data from "real" data with tags or separate repos. Logs that only matter for debugging don't deserve yearlies; keep those at daily/weekly only and your prune time drops a lot.
• Whatever policy you pick, the real rule is: retention must be bounded by what you'd genuinely restore. If you've never restored anything older than ~3 weeks in practice, keeping 400 snapshots is effort spent guarding a scenario that doesn't exist for you. Pick the tiers, prune once, and stop thinking about it.
• One more: verify with restic check --read-data-subset=x% on a schedule. A retained snapshot you've never verified is a hope, not a backup.

As of now, i keep them basically for ever, but granularity gets less over time. (restic forget)

Before you go nuts about files you want to exculde the "churn" as you said it, go ahead and actually check how much space this actually takes up. Text and especially logs are highly compressible and will most likely end up taking up almost no space.

Be sure you backup everything you actually need, rather backup a file more then a file too less.

I use nightly backups. I keep them 2 weeks.

After that I keep a weekly backup for 2 months.

After that I keep a monthly backup for 2 years.

I keep my yearly backups forever.

I have daily backups, weekly, monthly and yearly. All but yearly is deleted after a certain time, but yearly I keep forever.

Daily for 10 days, 4 weekly, 4 monthly.

That covers me from broken updates, generally.

I learned I pretty much never need old data for my hobby selfhosting stuff. So I do 4 weeks. I'll notice if something breaks within 4 weeks and fix it. I occasionally do manual backups, for example when migrating stuff and keep them for longer. And I got some old stuff like in xkcd 1360.

I suppose I could do more, but I also want the privacy policy of my online services to say: x weeks and all the logs and unnecessary data is gone.

My VPS gets a weekly rsync to my home server. I keep ten deduplicated copies for weeks gone by. The current week also gets synced off-site with encryption.

7 backups, though the frequency they're taken (daily Vs weekly Vs monthly) depends on the service.

Why don't you exclude logs from your backups? databases sure yes that's where the real info is (not sure why you don't consider it real data) but logs are useless outside of the current running instance.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

4 acronyms in this thread; the most compressed thread commented on today has 8 acronyms.

[Thread #137 for this comm, first seen 17th Oct 2026, 15:00] [FAQ] [Full list] [Contact] [Source code]

I just buy new HDDs.

[forget]
keep-daily = 10
keep-weekly = 4

Daily backups are cheap because of de-duplication. I keep a few weekly backups in case it takes me a bit to notice something went wrong. I don't usually back up logs.

I could probably drop the weekly backups without much risk, but I've got the space.

I was backing up multiple places on my LAN but than half of my place flooded, so lamenat and carpet was ripped up, one of my pi 5’s was misplaced with a NVMe drive and another was lost. Than just down the street 3 house went up in flames had the wind been blowing just a little south my condo complex would have been burnt to the ground. After the fire fighters were telling us to get back further and further I had my main pi 5 that had all the backups of everything important on another NVMe drive and a few other things ready to go if the firefighters started banging on my door telling me it was time to leave. I wish I could honestly say that was the day I decided to get a VPS and start my back up, but I was still hoping my father would let me set up a pi with a drive big enough to do back ups at his place. It sounds like he will but he is concerned about security risks about my VPN, funny thing is my back up pi would be the most secure thing hooked up to his modem/router and I wouldn’t want his stuff touching my stuff and with how my LAN and VPN are set up they would have a hard time doing it. Anywho I have a domain hosted by EasyDNS, and just went and looked at their VPS options and got some year long plan and set up cron jobs to take the stuff I want to backup and use age to encrypt it and than it is sent to my VPS each age container is than deleted after there is something of the same name but 3 days iterations older and deletes it.

How long do you keep your backups?

Yes, I have that exernal HDD lying around somewhere near the PC, and it was at least 4 or 5 times that I backed up a lot of files on it.

I think I keep it for more than 10 years now.

I use bormatic, I can go back about 60 days and have needed to a few times in the past due to my own mistakes. Server is in the basement, it backs up toy living room TV pc which is on the top floor. My upload speed is too slow for offsite backups.

Let me put it this way: I have a removable harddisk with my files from the universities' VAX 11/780 in storage. Long enough?

As long as I have space. My backups are on dedicated drives, and as they run out of space the old ones are deleted.

I backup once a week. I have 3 backups (in 2 locations). Everytime a new one is created, the oldest is deleted. I figured if I need to roll back something, 3 weeks is more than enough to notice.

Zero or one backups depending on the type of data generally.

For a system if it can't be redeployed from a list of requirements then I Foundationally ducked up. It means either I'm depending on something fragile, unknowable or over complicated.

Raw data on the other hand goes on a raid array. If I need more redundancy then that, then a single extra off site backup on a cd or something.

A back up on the same drive as the original isn't a backup. It's a waste of space, and a stupid idea.

A system that requires excessive nonsense is not reliable.

If I have a on and off site back up and both fail. Then either the world is literally fucking on fire and it doesn't matter. Or someone dropped a bomb on my storage.

Either way I have bigger problems at that point.