Pull mode

[test-account-0]

I would like to vote for a pull mode feature.

There is already 'attic serve', but it is spawned by attic with ssh.
I would like something like 'attic client' listening on a tcp port, where 'attic serve' would initialize backup from a central server. And there should be possibility for mutual certificate based authentication.

Advantages of that solution are:

• You can SCHEDULE backups from one point,
• cofiguration of the clients in one place,
• improved security:
  • both client and server don't have to be trusted,
  • there should be an easy way to disable client from deleting backups,
  • no way to initiate connection to the server from client,
• easier way to develop webinterface.

And probably more.

[dnnr]

• improved security:
  • both client and server don't have to be trusted,

Keep in mind, that this puts much harder requirements on attic with regards to security. One tiny vulnerability, and the pulling server becomes the weakest link between an attacker and full access to all backed up clients.

In a push setup, on the other hand, the worst case scenario is remote code execution with the privileges of an attic-specific, otherwise powerless user account on the server. And with all remote data being encrypted, the worst case scenario is deletion of backups, which is far less bad. And there are effective mitigations available, like filesystem snapshots.

[gaussgss]

Keep in mind, that this puts much harder requirements on attic with regards to security. One tiny vulnerability, and the pulling server becomes the weakest link between an attacker and full access to all backed up clients.

Much better than having server ssh private keys on each machine. The possibility for malicious client to erase whole attic repository or putting some 0day malware in the shell is not the kind of security that i want.

Connecting to client over ssh and running attic client will protect it from being hacked via flaws in client code.

[ThomasWaldmann]

+1 for pull mode.

[dahjelle]

I'd love this, too!

I've a "workaround" that I've been using that I'd love comments on, if anyone has them. Basically, I have a client machine that has attic installed and a backup machine that does not have attic, but does have SSH access to the client machine. (client does not have SSH access to backup.)

client must have enough local hard drive space to store the attic repository.

Then, from backup, you can trigger both attic and a rsync to copy the attic repository locally:

ssh client "attic create ~/client-repo.attic::$(date +Y-%m-%d)"
rsync --archive --compress --verbose --delete client:~/client-repo.attic/ ~/client-repo/.

It definitely doesn't address all of the advantages of a pull mode, but it gets a couple.

My big question: using rsync to copy to repo after the backup seems to generally work, but is this unsafe for any reason that I should be aware of?

[wscott]

I would be surprised if --compress helps at all since the backup is already
pretty compressed.

Would something like this work?
ssh -R 8888:localhost:22 attic create
ssh://localhost:8888/client-repo.attic

You setup a tunnel from the remote machine to back to ssh on the server.
Now the client and connect with the data tunnelled over the original
connection.

I haven't tried it, but it seems like it could work.

On Wed, May 6, 2015 at 11:27 AM, David Alan Hjelle <[email protected]

wrote:

I'd love this, too!

I've a "workaround" that I've been using that I'd love comments on, if
anyone has them. Basically, I have a client machine that has attic
installed and a backup machine that does not have attic, but does have
SSH access to the client machine. (client does not have SSH access to
backup.)

client must have enough local hard drive space to store the attic
repository.

Then, from backup, you can trigger both attic and a rsync to copy the
attic repository locally:

ssh client "attic create /client-repo.attic::$(date +Y-%m-%d)"
rsync --archive --compress --verbose --delete client:/client-repo.attic/ ~/client-repo/.

It definitely doesn't address all of the advantages of a pull mode, but it
gets a couple.

My big question: using rsync to copy to repo after the backup seems to
generally work, but is this unsafe for any reason that I should be aware of?

Reply to this email directly or view it on GitHub
#175 (comment).

[dahjelle]

Yeah, I didn't measure it, but I took out --compress later for exactly that reason.

@wscott, that's an interesting idea I hadn't thought of! I'm not super familiar with the -R option, though: does it require client to authenticate to backup somehow? The ability of client to authenticate to backup was one of the things I was trying to avoid. Or am I misunderstanding what -R does?

[wscott]

ssh -R cause a tunnel to be created so that connections to one port on the
remote machine are actually made to another port on the local side of the
connection.

So I did the simple case of just mapping a port to the local side's ssh
daemon. I have remote machines where I can connect to them directly, but
they can do the reverse because my desktop is not on the internet directly
but behind a NAT firewall. This tunnel solves that problem and allows the
connection.

We could do one better and use 'nc' and a fake 'ssh' executable so that
when the remote attic tries to create a ssh connection it actually talks to
a local 'attic serve' process.

All of this would be easier if attic had some better support for this sort
of thing.

On Wed, May 6, 2015 at 3:21 PM, David Alan Hjelle [email protected]
wrote:

Yeah, I didn't measure it, but I took out --compress later for exactly
that reason.

@wscott https://github.com/wscott, that's an interesting idea I hadn't
thought of! I'm not super familiar with the -R option, though: does it
require client to authenticate to backup somehow? The ability of client
to authenticate to backup was one of the things I was trying to avoid. Or
am I misunderstanding what -R does?

Reply to this email directly or view it on GitHub
#175 (comment).

[jasonfharris]

+1 for some sort of pull mode. If you have a server that is exposed to the net through multiple attack surfaces (web, email, etc) then it is much more likely to be compromised that an extremely locked down backup server which just has ssh enabled on it. It would be nice if the client machines had an easy way to be set up so that an account with read only ssh privileges to just the directories to be backed up could be created. So that even if the backup server is compromised at the worst they will be able to only read the contents to be backed up.

[fabianlaule]

+1 I'm also for a pull mode.

[nckbnv]

I would like a pull option too...

[trbarbour]

+1 I would also like a pull option.

[anarcat]

after a quick review, it seems that Obnam does "pull" through sftp. it has a VFS layer to access filesystems locally or through SFTP transparently that is pretty neat, but in the end all this happens through SSH anyways, so i guess that people wanting to implement pull backups now could use sshfs to mount the client from the server side and run attic through that.

[haffenloher]

i guess that people wanting to implement pull backups now could use sshfs to mount the client from the server side and run attic through that.

I tried that, but occasionally it leads to a full retransmission of the data, so it's not really a bandwidth-efficient solution.

[ThomasWaldmann]

@brumsoel correct. sshfs (and even more sftp, due to small and unchangeable block size) would have bad performance.

In fact everything reading the data source via a (network-)fs-like thing will have bad performance as duplicate file contents will first go over the network before they reach attic (and its chunker cuts chunks which may be identified as duplicates).

[bopolissimus]

+1 for pull mode. mainly for jasonfharris' security reasons.

#175 (comment)

[leaf-node]

What about implementing something ssh-y so you have the feature now, then fix performance issues later? It wouldn't be any worse than other systems that use ssh for backups.