3 ms·
Looks nice. How fast is it? I wonder if you could make this into a simple off-site backup system for databases. It might require some more complex interaction w
by paul 18y ago
Looks nice. How fast is it? I wonder if you could make this into a simple off-site backup system for databases. It might require some more complex interaction with the db or os to do it right though (since the data is changing while you are reading it).
- SkylerNovak 18y agoMy question precisely.
- cperciva 18y agoHow fast is it? How fast is your internet connection? On a decent CPU the tarsnap code can easily push 50 Mbps -- the largest part of its time is spent in zlib, compressing data before it is encrypted and uploaded -- so the limiting factor is almost certainly going to be bandwidth. I wonder if you could make this into a simple off-site backup system for databases. Tarsnap isn't likely to be useful for "real time" replication, but if you get your database to write a transaction log you might get interesting results by having tarsnap loop creating archives containing that one file.
- paul 18y agoI was thinking of the snapshot speed, where most of the data hasn't changed. Do you keep a local cache of block checksums or something to avoid having to check the server? How about an option to not examine the data if the file size and mtime haven't changed? (like rsync does)
- cperciva 18y agoI was thinking of the snapshot speed, where most of the data hasn't changed. On modern CPUs, somewhere in the 20-50 MB/s range. Do you keep a local cache of block checksums or something to avoid having to check the server? Yes. How about an option to not examine the data if the file size and mtime haven't changed? (like rsync does) Tarsnap already does this for unmodified (file name, inode number, file size, mtime) tuples.