[Dirvish] Backing up Windows computers

Eric V. Smith eric at trueblade.com
Mon Mar 10 00:14:29 UTC 2014


No offense on "convoluted". It's quite accurate.

Looking at the source code, I see that the logging is a compile time
option. Bummer. Maybe I'll look at making that an argument you can pass
through the "tree" parameter. Of course I'll have to find a Visual
Studio compiler first.

So are you saying that you can ssh in to the Windows box, but you can't
use tb-rsync-vss? And the only thing you see on the dirvish side is a
broken pipe error? Is there anything in rsync_error in the dirvish image
directory?

This is from my config file:
client: Administrator at 10.10.15.2
tree: "/|tmp-drive=x|rsync=c:/opt/cygwin/bin/rsync.exe|cygpath=true|c:/home"

That configuration worked as recently as a few weeks ago, when that
Windows machine died. But not to worry, it was backed up!

Eric.

On 3/9/2014 7:50 PM, Gibson McNeil Boyle wrote:
> Thanks Eric for the quick response.
> Copssh (OpenSSH 6.5p1) and cwRsync (Rsync 3.1.0) are both based on
> Cygwin 1.7.27 hence the use of cygwin drive notation is not an issue.
> The master.conf file used was the same with and without ssh while the
> default.conf file used with ssh (set up successfully for connection
> without a password) is as follows:
> 
>     client: dirvish at 172.20.10.11
>     tree:
> "/|tmp-drive=x|rsync=c:/Copssh/ICW/bin/rsync.exe|cygpath=true|c:/Work"
>     index: text
>     log: text
>     expire-default: +15 days
>     rsync-client: "c:/Program Files/True Blade Systems/tb-rsync-vss-32.exe"
>     numeric-ids: 1
> 
> In the case without tb-rsync-vss, the tree string used was
> /cygdrive/c/work while the rsync-client entry was commented out
> 
> I am sorry about the use of the word 'convoluted' but I was at a loss of
> a better expression to use at the time and I agree with you that in this
> instance of a pull transfer of data to the location of the dirvish
> routines and the transfer of all parameters in the rsync mode, there
> probably is no better option.
> 
> I await your feedback once you have your instances up and running
> 
> Regards
> 
> Gibson
> 
> 
> On Monday, March 10, 2014 12:01 AM, Eric V. Smith <eric at trueblade.com>
> wrote:
> On 03/09/2014 06:24 PM, Gibson McNeil Boyle wrote:
>> I have dirvish setup and tested using both ssh (copssh) and rsync
>> (cwRsync). Both utilities are available from www.itefix.no. The setup is
>> backing up a windows folder to a NAS (linux platform). Tests copying
>> files with and without ssh (rsync daemon) were successful.
>>
>> To overcome the issues associated with rsync while copying open/locked
>> files, I tried out Eric Smith's tb-rsync-vss-32 wrapper. Unfortunately,
>> dirvish returned broken pipes errors using ssh. I used a default.conf
>> file very similar to the example provided in the Bitbucket article.
> 
> Hmm. There's some way to have tb-rsync-vss-32 produce a log file.
> Coincidentally, I'm setting up a new Windows machine so I have occasion
> to look into the source code this week. I'll report back on my progress.
> 
>> I shall be grateful to hear about the experience of other users with
>> this tb-rsync-vss utility..
>> 1. Is it necessary that I must use cygwin, sshd and rsync instead of
>> copssh and cwRsync?
> 
> I don't see why cygwin's versions of these tools would be required. The
> code does nothing cygwin specific, that I know of. It does know about
> cygwin specific paths, but there's a documented way to turn that off.
> It's probably not well tested.
> 
>> 2. If the tb-rsync-vss utility and its convoluted parameters is a
>> logical replacement for rsync, should it not be useable in all cases
>> where rsync is used including when run as a daemon in a secure network
>> possibly with the addition of an extra colon at the beginning of the
>> tree string in the default.conf file?
> 
> Heh. "Convoluted" is an understatement. I'm open to ideas on making it
> simpler, but if you live with the restriction that all of the
> configuration must be done on the side running dirvish and passed via
> "rsync" command line parameters, I don't see what other choice you have.
> 
> I don't think it could replace the "rsync as a daemon" scenario, because
> it doesn't listen to any sockets. It relies on ssh starting it up,
> thinking it's a non-daemon version of rsync. Maybe it could be made to
> work with inetd doing the listening, but I've not thought it through
> (nor tried it, obviously).
> 
> I hope that helps. When I get my new instance installed, I'll let you
> know. I'll be running the 64 bit version, but the source code is
> identical between the two versions.
> 
> Eric.
> 
> 
> _______________________________________________
> Dirvish mailing list
> Dirvish at dirvish.org <mailto:Dirvish at dirvish.org>
> http://www.dirvish.org/mailman/listinfo/dirvish
> 
> 
> 
> 
> _______________________________________________
> Dirvish mailing list
> Dirvish at dirvish.org
> http://www.dirvish.org/mailman/listinfo/dirvish
> 


More information about the Dirvish mailing list