Salta al contenuto principale

mastodon - Collegamento all'originale

Does anyone have recommendations for Windows full-volume/system backup tools that are friendly to syncing to offsite backups?

I'm currently using Veeam agent. It works fine locally, but then I use restic to sync the backups over to offsite. The problem is that the way it manages backup lifetime is by taking the oldest full backup and "merging" in the next incremental (and renaming the file to the next date), to keep the total backup count constant. That means every day, Restic has to process a new "full backup" file.

Thanks to deduplication it doesn't actually copy the whole thing, it still only backs up changed chunks, but it still has to read and hash 1TB+ of data which takes hours...

in reply to Asahi Lina (朝日リナ) // nullptr::live

Chris
mastodon - Collegamento all'originale
Chris
• •
can't you use Veeam with Tailscale (or something similar) to also do the off site backup?
in reply to Chris

Asahi Lina (朝日リナ) // nullptr::live
mastodon - Collegamento all'originale
Asahi Lina (朝日リナ) // nullptr::live
• •
@RyuKurisu I don't want to back up twice, I want to back up once and sync the backup to offsite. The sync process runs on Linux.
@Chris
in reply to Asahi Lina (朝日リナ) // nullptr::live

Chris
mastodon - Collegamento all'originale
Chris
• •
ever considered Syncthing? It is a synchronisation tool that runs in the background. It also has the option ignore deletions on the remote.
in reply to Asahi Lina (朝日リナ) // nullptr::live

Asahi Lina (朝日リナ) // nullptr::live
mastodon - Collegamento all'originale
Asahi Lina (朝日リナ) // nullptr::live
• •
If it only did this weekly or something (having a variable backup count across the week and only cleaning up weekly) then it'd be fine, but daily is a bit too much...
in reply to Asahi Lina (朝日リナ) // nullptr::live

Asahi Lina (朝日リナ) // nullptr::live
mastodon - Collegamento all'originale
Asahi Lina (朝日リナ) // nullptr::live
• •
I'd missed this, but apparently Veeam can be configured to do monthly full backups, and in that case it *should* not touch the old incremental chain until it falls off the schedule. Maybe this is all I really need?
in reply to Asahi Lina (朝日リナ) // nullptr::live

Asahi Lina (朝日リナ) // nullptr::live
mastodon - Collegamento all'originale
Asahi Lina (朝日リナ) // nullptr::live
• •
Yeah, I think this works. Last night's backup didn't consolidate anything any more. Tomorrow is a new month, so it should do a new full backup and then go on that cycle.
in reply to Asahi Lina (朝日リナ) // nullptr::live

Asahi Lina (朝日リナ) // nullptr::live
mastodon - Collegamento all'originale
Asahi Lina (朝日リナ) // nullptr::live
• •

All good! The new full backup was 470GB (a lot of files were moved off of this drive, used to be 1.4TB), and of that 167GB was copied to the repo (156GB compressed, no surprise it's not very different because Veeam itself compresses). So the full backup approach works, and restic's dedup and chunking plays well enough with Veeam's format, even with compression.

I should blog about all this backup stuff.. ^^

Unknown parent

Asahi Lina (朝日リナ) // nullptr::live
mastodon - Collegamento all'originale
Asahi Lina (朝日リナ) // nullptr::live
• •

@helmet91 Isn't that file based? The point of doing volume based backups is you can easily restore a working OS.

If I'm switching to file based, I'd just run restic directly (native builds exist).

in reply to Asahi Lina (朝日リナ) // nullptr::live

Gabriel Adrian Samfira
mastodon - Collegamento all'originale
Gabriel Adrian Samfira
• •
sadly, I don't know of any already made solution, but if you have the time, writing one is not impossible. Veeam backup, most likely uses Windows VSS (volume shadow copy services) which creates a copy-on-write snapshot of volumes. If it's block level backup you're looking for, then it probably chunks the entire volume, takes note of empty chunks, copies non empty ones, creates a state file in which you save the ID, use that ID in the next incremental backup to get only changed blocks.
in reply to Gabriel Adrian Samfira

Gabriel Adrian Samfira
mastodon - Collegamento all'originale
Gabriel Adrian Samfira
• •

On the bckp site, you can periodically squash the (initial)full backup and it's immediate child bckp to keep the number of backups constant.

To restore, you can compose a raw disk file from the base backup and apply each incremental backup on top. This can be optimized if you walk through the state files, and take only the final offsets of blocks to the point in time you want to restore to and apply them on your base backup. If bkup 1,2,3,5 all changed block X, you only neex blk X from 5.

Questa voce è stata modificata (1 mese fa)
⇧