3 ms·
While we use tarsnap for our server backups, it's not something I'd use for frequent desktop backups. The main reason is that it doesn't have a daemon that wat
by wheels 15y ago
While we use tarsnap for our server backups, it's not something I'd use for frequent desktop backups.
The main reason is that it doesn't have a daemon that watches file changes to keep a dirty list so it'd basically DDoS your desktop every time the cronjob ran to run the backup. Also for a desktop it's nice to have an interface where you can see the differences between backups.
The I/O thing is actually a problem on servers too. See if you can spot the point in this graph where cron.daily runs:
https://skitch.com/scotchi/gjbyc/generate-graph https://skitch.com/scotchi/gjbyc/generate-graph
- 286c8cb04bda 15y agoExcuse my presumption if you already know about this, but there are ways to make the I/O less aggressive for processes that hit the disk hard. Since your graph header says 'linode', I'm assuming your servers all run Linux, and you should take a look at ionice[1]. It adjusts the IO priority of a process like 'nice' adjusts CPU priority. For example, prefixing your call like this: "ionice -c 3 tarsnap...." will give tarsnap the lowest priority access to the drive. [1] http://linux.die.net/man/1/ionice http://linux.die.net/man/1/ionice
- cperciva 15y agoHave you tried using the --disk-pause option? That should allow you to slow Tarsnap down so that it doesn't eat all your I/Os. (For desktop systems with limited internet bandwidth, the --maxbw-rate option is probably worth investigating too, unless you want your web browsing to slow down significantly.)