On Wed, Nov 05, 2003 at 02:36:46PM +0100, JC Simonetti wrote:
> On Wed, 5 Nov 2003 04:52:33 -0800
> David Wolfskill <david AT egation DOT com> wrote:
> > I wasn't aware that the Win32 environment was sufficiently "special"
> > that tar archives were unportable between that and normal (UNIX)
> > environments.
> It's the reason of the existence of the WinTar software :)
Oh. I had (perhaps naively) thought that it was merely a win32/NT/...?
port of a more standard tar....
> > Well, I suppose it might be, if it were small enough to fit in the
> > available space on the Windows box, and if someone who had a clue about
> > the Windows environment (i.e., not me) did it. But it's a (Win32) tar
> > archive for the entire "C:" drive.
> Whoops... Try a smaller tar to make your tests...
Well, I suppose any sub-tree would be somewhat smaller, but I have no
idea how Microsoft spells "du".
> I did not use amrecover for my restorations, but just amrestore. Why? Because
> in my backup architecture, I d not want to restore to data directly on the
> client but I restore them on the backup server then push them on the client.
> And as WinTar and GnuTar are different, I was just able to extract the dd
> image from the tape with amrestore and push these data on the Win32 server,
> and over there untar them.
> But I was backing up small data, something les than 5 Gb, so I was able to
> have on my Windows box the tar and the untar data simultaneously, right :)
Ah. Well, nearly anything that is done around here involving a
Microsoft platform will need to be done by someone other than me: they
seem to be remarkably unreliable around me. (They probably know what I
think of them....)
> Concerning development on Win32 architectures, you have Dev-C++
> (http://sourceforge.net/projects/dev-cpp/) : a free software IDE compiler
> under Windows.
Well, for whoever does the development, that might be useful; thanks.
> Personally I don't like the Win32 client since it is based on a CVS snapshot
> of Amanda from august 2001 : so old isn't it?!
Understood. I believe that my employer would be willing to pay someone
to re-do that work, with a more recent version of the source.
> Maybe a future development of this client should only be libraries to
> interface the *nix version of Amanda under Win32, maybe real libraries or
> patches to apply on the sources, but something that would be generic and not
> applied on a particular version and just on this version.
Maybe in the longer term; for now, we just want something that actually
works.
> The 2 other solutions are :
> 1. Samba backup using "smbclient" on the Linux Amanda server: simple but you
> do not backup NT file rights (well... see some messages above in the
> mailing-list, someone sent a little script to backup the rights)
Yes, I know of this. However, in our environment, it is not an
acceptable approach.
> 2. Cygwin and the Amanda source code: very functional but you have to install
> a Linux emulator on your Windows box... I don't like the idea (what would you
> say if I told you that you have to install a Windows emulator on your BSD to
> backup your BSD?)
Right; I expect that Cygwin will be involved, but only for development.
We are trying to minimize the impact on clients' machines.
Thanks again,
david
--
David H. Wolfskill david AT egation DOT com
|
