1 |
>> I'm backing up numerous large files on another machine on my local |
2 |
>> network. I've only been using rsync, but it occured to me that I |
3 |
>> might be able to save some time and space if I incorporate tar and |
4 |
>> bzip2. How will rsync interact with those? If I turn the whole |
5 |
>> backup into a big tar.bz2, would rsync need to redownload the whole |
6 |
>> thing if I change one file? If so, maybe I should turn different |
7 |
>> groups of files into tar.bz2 archives so rsync only needs to |
8 |
>> redownload an archive if one of its files has changed? |
9 |
> |
10 |
> It's not a default behavior, but there is an '--inplace' option. |
11 |
> |
12 |
> Also,there is a '--compress' option, if the bandwith is the only |
13 |
> problem, otherwise you can use lzma (with normal-best ratio) to either |
14 |
> acheive much better compression than bzip2 or still slightly better |
15 |
> ratio with improved speed / less cpu time with 'lzma -1' (fast mode). |
16 |
> |
17 |
> And if you're going to put a lot of files (like whole fs) into a |
18 |
> single tar just to transfer it to some remote destination, prehaps you |
19 |
> shouldn't be using rsync at all, since you'll end up reading all the |
20 |
> files anyway to create the tar. |
21 |
> Alternatively, you can save disk space on the source machine by piping |
22 |
> tar directly to destination, with compression either on the source to |
23 |
> lessen the banwidth, or on the remote to lessen the load on the source |
24 |
> machine cpu. |
25 |
> |
26 |
> That said, you can also use tar to create (or pipe) incremental backups |
27 |
> - just the changes since the time last one was made. Tar can handle that |
28 |
> as easily as rsync does, since it checks what needs to be transferred |
29 |
> each time anyway. |
30 |
> |
31 |
> -- |
32 |
> Mike Kazantsev // fraggod.net |
33 |
|
34 |
Good stuff, thanks a lot Mike. |
35 |
|
36 |
- Grant |