busybox's tar doesn't have options to preserve owner, permission or attributes, therefore we need to provide a tar binary.

I know we talked about rsync before but I can't recall whether you tested it?

The rsync man page[1] says that rsync can:

"can  copy  locally,  to/from  another  host  over  any remote shell, or to/from a remote rsync daemon"

1. http://manpages.ubuntu.com/manpages/precise/en/man1/rsync.1.html

(In reply to comment #2)
> I know we talked about rsync before but I can't recall whether you tested it?
> 

I haven't tested it yet, the issue with rsync was that we needed to provide the binary in the target, but now we need to provide tar, so rsync becomes a viable option again. I'll try rsync next.

(In reply to comment #3)
> (In reply to comment #2)
> > I know we talked about rsync before but I can't recall whether you tested it?
> > 
> 
> I haven't tested it yet, the issue with rsync was that we needed to provide
> the binary in the target, but now we need to provide tar, so rsync becomes a
> viable option again. I'll try rsync next.

My understanding of the manpage is that the binary shouldn't be required on the target, because rsync can copy "to/from  another  host  over  any remote shell" — thus I'd expect if we have rsync-native on the host we can rsync to the target.

(In reply to comment #4)
> My understanding of the manpage is that the binary shouldn't be required on
> the target, because rsync can copy "to/from  another  host  over  any remote
> shell" — thus I'd expect if we have rsync-native on the host we can rsync to
> the target.

I tested that, you need rsync in both hosts

unfortunately, the enhancement window is over, so moving it to 2.5.

is this something we still need to test?

This doesn't seem to be a problem in our current workflow. Reopen if it becomes one.