Alternative rsync client for Windows

[L. A. Walsh]

Kevin Korb wrote:
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> 
> I come from the Linux world.  If one of my computers were to simply
> evaporate into nothingness or have complete storage failure then once
> the hardware problem is dealt with I would network boot SystemRescueCD
> then restore my backups that I made with rsync.
> 
> I understand that things are more complicated in Windows but if say my
> laptop (it is the only computer I have that both boots and stores
> Windows) were similarly destroyed or blanked I would still network
> boot SystemRescueCD and restore my backups that I made with ntfsclone.
> 
> My hesitation with backing up a Windows system with rsync is that
> I have absolutely no idea to go from "I have a blank computer and
> a copy of all my files" to "I have a working computer with all my
> stuff".  I might be asking for something as simple as "Install
> Windows, install Acrosync, restore everything including the Windows
> configuration from backups" or maybe some kind of rescue disc or maybe
> some kind of custom WinPE disc.  I don't know.  I know just enough
> about Windows to figure out how to use what I know from Linux to make
> things sorta work.
---
I wouldn't suggest trying to restore windows w/rsync.  It might be
possible, but first issue is that whatever media you rsync things to,
needs to support full NT security and be able to create arbitrary
users/acl's to fully replicate the source.

Second issue is that MS deliberately uses things the location of
something on the disk as a "security option".  I don't know what
software uses it, but I remember discussion about "media licenses"
(❝𝑐𝑜𝑛𝑡𝑒𝑛𝑡❞) using the feature to prohibit any "copy" of them from working:
only the original in its original 'licensed' location would work.  The
whole way NTFS is designs it's locking of files is very unlike how it's
done on linux/unix.  When it locks a file, it isn't, like in linux, at
the inode level+offset; it's at a physical location on the disk that
gets locked... it's really primitive, (and is why one needs to often
reboot a system to replace binaries -- because the bytes on the disk ARE
the file and they are locked -- vs. on linux, usually you have an inode
that points to sectors where the file is, and by changing where the
inode points, you can change the content.

That said, my primary concern would be the first issue (for me, not
using licensed content on windows, I've not run into the problem, so
that's mostly from memory about how it was implemented.  VERY often,
when doing copies with rsync or cp -a from one sys to another, I'll find
permissions or such won't get transferred "quite" the same way.

I have used rsync from/to the same disk to restore & repair a broken
windows install -- the part that has problems is storing the extended
stuff and ACL's on a foreign media.

(Also have to make sure on restore that rsync has all needed
rights&privileges.  Cygwin takes care of alot of that -- removing
a file or such that in the windows command line, you'd have a pretty
hard time doing... or setting permissions on all the files in the
windows/system32 dir despite not "owning them" - under the posix model,
ownership doesn't matter for 'root'.. so cygwin tries to emulate that as
much as possible -- probably why I've seen cygwin listed as a "security
hacking tool"...;-)  (really!, letting a user control their own system,
how absurd!)..