New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
3-2-1 Strategy
Imap-backup for emails. Run it with cron as often as needed.
3-2-1
COPY /R C:\Users\sunny D:\backup\Kopia Repository server as the backup machine so maintenance gets done locally and then Kopia containers on the machines im backing up. If for whatever reason those machines can't run containers then I use the standalone kopia binary to backup to the kopia repo server.
Charityhost 500GB storage
I often backup manually
The thing I'd add that I'm not seeing much of in here: test your restores, not just your backups. restic check and a green cron log only prove the repo is intact, not that you can actually get data back. I run a job that pulls a real file out of the backup and sha compares it against the source on a schedule, so a broken restore surfaces on a boring Tuesday instead of during an actual incident. restic's rest-server backend makes that easy to automate (+1 to @rcy026 on that), and because the repo is portable I can rsync it to a different provider if one goes bad, no lock-in.
@DataRecovery on email: the trick is don't back up the live maildir, snapshot it. imapsync to a second mailbox for a warm copy, or pull a nightly dump and run restic against the dump rather than the running store, so you're not catching it mid-write. Restores are then just a normal restic restore into a throwaway IMAP account to verify before you trust it.
Disclosure since it's relevant: I run ServerCrate, a small zero-knowledge restic backup host, so I'm biased toward the restic-offsite approach. But the restore-testing habit matters whatever backend you use.
Streaming immutable objects across vendors/regions with immutable snapshots that can be branched/recovered from. Automated daily recovery test on fresh clusters.
Better than typical 3-2-1 with less overhead: 2+ offsite copies across 2+ vendors/regions, metadata only per snapshot overhead. RPO/RTO less than 10 minutes regardless of backup size (EiB scale).