Re: [Bacula-devel] Restoring a Windows system from Linux

[James H. <jam...@be...>]

> 
> Le dimanche 25 octobre 2009 10:24:30, James Harper a écrit :
> > > Le dimanche 25 octobre 2009 05:14:14, James Harper a écrit :
> > > > A year or two ago I was pondering about the best way to restore a
> > > > Windows system to 'bare metal'. BartPE is kind of nice for XP and 2003,
> > > > but is fairly specific on what platforms it supports, is legally
> > > > questionable if you are using OEM licenses, and in order to restore an
> > > > XP system you need access to files from Windows 2003 etc. I then looked
> > > > at what would be involved in booting Linux (via CD/USB/netboot/etc) and
> > > > then restoring that way. At the time though, the ACL's, ownership, and
> > > > a whole load of other stuff would be missing so there didn't seem to be
> > > > much point pursuing it.
> > > >
> > > > The latest 'Advanced' release of ntfs-3g supports direct access to the
> > > > ACL's, ADS's, NTFS Attributes, DOS filenames (eg the 8.3 filename
> > > > equivalent of the Windows filename), datestamps, and possibly EFS too.
> > > > So in theory, it would be possible to extend processWin32BackupAPIBlock
> > > > to not only write out the regular file data, but also to write out the
> > > > ACL's, ADS's, etc etc. I don't even think it would be that much work...
> > > > although I've been famously wrong about such things before :)
> > >
> > > Would be nice, but it's a terribly difficult reverse engineering
> > > process....
> >
> > I haven't done much investigating yet, but I believe that the magic code
> >  that currently retrieves the file data from the BackupRead (windows backup
> >  api) stream just searches until it finds the right stream. Ntfs-3g can get
> >  and set raw ACL data which I believe is in one of the BackupRead streams
> >  already. Ditto for the ADS's. Not sure about NTFS Attributes and DOS
> >  filename though.
> 
> The problem is that it could change over the time and versions, but it's
> interresting.
> 

At it stands right now, with an ntfs-3g mounted volume 'getfattr -h -e hex -n system.ntfs_acl <filename>' retrieves a hex string that is byte for byte identical with what comes out of the BACKUP_SECURITY_DATA in the BackupRead data stream. (the BackupRead decomposition code singles out the BACKUP_DATA stream and ignores everything else).

Are you concerned about the xattr interface to ntfs-3g changing, or the format of the data produced by BackupRead and consumed by BackupWrite?

I'm not yet convinced that either the above or the run-windows-in-a-vm solution is best, but there are still a lot of non-server devices that don't have hardware support for virtualisation, so doing it the virtualisation way leaves workstation rebuilds without a solution... (if that's a concern for you - maybe not?)

James