1 |
On 26 February 2010 01:11, Ward Poelmans <wpoely86@×××××.com> wrote: |
2 |
> On Thu, Feb 25, 2010 at 16:41, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
3 |
>> A much better way is to run a dedicated agent on the client. If the server |
4 |
>> needs to schedule backups, it can ask the agent to do so using regular tcp |
5 |
>> traffic. The client can then do it's backup and rsync it over to the server |
6 |
>> when it's done, and that push can be done as a regular user on both ends. The |
7 |
>> actual backing up on the client must be done by root of course, no other user |
8 |
>> has the necessary access. |
9 |
> |
10 |
> Sounds great. Is there any software that works this way? |
11 |
> |
12 |
> Ward |
13 |
|
14 |
Sounds more or less like cron tasks and rsnapshot to me (can use other |
15 |
rsync scripts of course, but this one is nice to me anyway, and |
16 |
someone else mentioned it earlier in the thread). I'm not sure off |
17 |
hand I have a good way for it to be initialized from the server end, |
18 |
but if it's a backup, it might as well run on a local cron anyway |
19 |
rather than needing an external call. |
20 |
|
21 |
As a simple idea, cron task starts rsnapshot configured however. When |
22 |
this is done, backup is tarballed, and tarball is given as like, say, |
23 |
440 permissions, where users are in some useful 'backup' group, then |
24 |
while tarball can be read to be passed across server, if tarball is |
25 |
extracted, user has no more privs then they have on the system anyway |
26 |
(I'm not saying chmod -R). Then local tarball can be removed or |
27 |
whatever. |
28 |
|
29 |
And call me silly for not reading documentation or assuming, but I was |
30 |
very happy last night when I realized system rescue CD includes |
31 |
rsnapshot already! |
32 |
|
33 |
~daid |