Member Avatar for sendres

I'm looking to develop a new strategy to provide both an on-site and off-site backup of my computer, which runs Windows XP.

The good news is I have shell access to a Solaris machine through my university, and my storage allocation on this server more than sufficient to back up everything. I also have some spare computers on-hand that I can use for an on-site backup machine. So I'd like to set up a system wherein:

  1. My main computer backs up to an on-site backup server each night.
  2. My backup server connects (over cable modem) to the remote university server the next day and updates those files. (I would expect the daily updates to be generally 100-200 MB at most.)

Here are my queries:

  1. I don't know all that much about *nix, but have read that rsync is the way to go for remote backups. Would it then be best/easiest if my on-site machine were set up on *nix as well? I assume I could then SSH/rsync to that server?
  2. If my backup server runs *nix, is it better to have it connect to my XP box via Samba, and fetch the files? Or to use some sort of XP to *nix backup program? (Note: I just need to backup 'My Documents', not do a full system backup/restore.) I would like, if at all possibe, not to use Cygwin.
  3. I need to encrypt the files on the university server for security. I don't care if my on-site backup is encrypted. Is it better for to have my on-site backup machine connect to my XP box via Samba, and fetch the files? Or to use some sort of XP to *nix backup program? At what point should I encrypt? (Note: I just need to backup 'My Documents', not do a full system backup/restore.)
  4. What happens to Windows file permissions when going to *nix?

I's appreciate any suggestions you might have. Thanks very much in advance...

Steven

  • 3 Contributors
  • 5 Replies
  • 107 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by sendres

Dani AI

Generated

— building on points raised by and , a practical, safe design is: keep a nightly, file-level copy on the on-site machine, and push encrypted incremental snapshots off-site. The important design choices are (A) how you capture consistent Windows files, (B) how you encrypt without breaking incremental transfers, and (C) how you verify restores.

Avoid creating one large encrypted archive if you want bandwidth-efficient daily updates. Encryption schemes that rewrite a single big file will usually make small changes look like large ones, forcing retransfer of the whole archive. Two better patterns:

  • Keep the file tree and back up per-file so only changed files are pushed.
  • Or use a backup system that does dedupe/chunking before encryption (so only changed chunks are uploaded).

A simple, robust workflow:

  • On XP, produce a stable export of My Documents (shutdown apps or use Volume Shadow Copy) so reads are consistent.
  • On the on-site Unix box, mirror that export into dated snapshots (rsync + hard-link rotation or a snapshot tool) so you retain history without duplicating unchanged data.
  • Before sending off-site, either encrypt changed files individually or use a deduplicating/encrypting backup tool; then push the encrypted data to the Solaris server over SSH with a key restricted to backup operations.

Small practical tips: export or record Windows ACLs if you must preserve them—ACLs don’t map 1:1 to POSIX and will otherwise be normalized to the copying account. Never embed plaintext credentials in scripts; use SSH keys with forced-command/restricted options or key passphrases with an agent. Schedule periodic test-restores and keep multiple rotations (daily/weekly/monthly) so corruption or accidental deletion can be recovered. Finally, check which backup clients/packages are available on your Solaris shell account before committing to a particular tool.

Recommended Answers

All 5 Replies

Member Avatar for jbennet

In terms of permissions, it shoulkd be fine. I recently replaced my ome Nt4 server with Samba and my client dont notice the difference

Member Avatar for John A

I don't know all that much about *nix, but have read that rsync is the way to go for remote backups. Would it then be best/easiest if my on-site machine were set up on *nix as well? I assume I could then SSH/rsync to that server?

To make things easiest, your backup server should be running *nix. It's fairly trivial to set up an rsync script that automatically copies backups to the remote server on a scheduled basis.

If my backup server runs *nix, is it better to have it connect to my XP box via Samba, and fetch the files? Or to use some sort of XP to *nix backup program? (Note: I just need to backup 'My Documents', not do a full system backup/restore.)

The simplest automated method for backing up would be to install Samba on your backup machine, then set up a cron job that automatically mounts and copies files from your Windows XP box.

I need to encrypt the files on the university server for security. I don't care if my on-site backup is encrypted. Is it better for to have my on-site backup machine connect to my XP box via Samba, and fetch the files? Or to use some sort of XP to *nix backup program? At what point should I encrypt? (Note: I just need to backup 'My Documents', not do a full system backup/restore.)

For security purposes, you should do the encryption on your backup server. I don't know much about cryptography in Unix, although it should be fairly easy to set up a cron job that will encrypt the files after they've been copied from your XP box. The result will be a single image/archive which your server can then upload to the university server.

What happens to Windows file permissions when going to *nix?

The ownership of the files will be whatever user you use to copy them onto the machine. It shouldn't be a problem.

Member Avatar for sendres

Okay, this makes a lot of sense to me. I guess the one wrinkle is that while the daily changes are on the order of 100-200 MB, the entire dataset right now is about 200GB. I know that rsync is efficient because it basically only sends the parts of files that have changed. But I wonder how the file encryption would affect the rsync efficiency, particularly if I have one big archive as opposed to maintaining individual files?

In other words, if I have an encrypted archive, does that prevent rsync from seeing only the portions that have been altered, and thus require it so send the whole 200GB?

Member Avatar for jbennet

yeah :(

Member Avatar for sendres

I just found some info on rsyncrypto, which apparently allows you to rsync encrypted files. The tradeoff is that the encryption is slightly weaker. This is a tradeoff I can live with, so I think I'm good to go.

Thanks!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.