Re: USB drives as backup medium

["Tom Metro-12" <user=71@nabble.blu.org>]

 jbk wrote: 
> Just finished a quick glance through "man rsync" and I think 
> I could learn to use it in a simple way at least at first. 
> But, a couple things come to mind when I consider what the 
> output of a backup or snapshot is. 

First, I'll echo Ben Eisenbraun's recommendation not to reinvent the 
snapshot wheel and select one of the existing solutions for that. They 
wrap around rsync and provide their own interface. See his message for 
suggestions. 

However, you may still want to do a simple trial run using just rsync by 
itself without the snapshot capability. 


> One is that I will be able to browse this device as if it were the 
> same file system as the original. On the surface this seems 
> convenient but what I would be worried of is that you could easily 
> get confused as to what is the original and what is the backup. 
> Non-Issue? 

It should be a non-issue. You should be clear what you are browsing 
based on the path. The specifics vary depending on the script 
implementing snapshots, but if your USB drive is mounted at /mnt/backup, 
you'll end up with a directory structure something like: 

/mnt/backup/current 
/mnt/backup/yesterday 
/mnt/backup/lastweek 
/mnt/backup/lastmonth 
/mnt/backup/3monthsago 
/mnt/backup/6monthsago 
/mnt/backup/9monthsago 

The naming and frequency of the directories is often configurable. Each 
directory will appear to have a full mirror of whatever file system you 
have backed up. 

Under the hood this is implemented by having the entries in 
/mnt/backup/current hard link to the files in /mnt/backup/yesterday that 
are identical, while files that are different are new independent files. 
This concept is repeated down the chain of snapshot directories. The 
hard linking permits saving storage space will still having a full 
directory tree that appears to mirror the original. 


> Let's say I rsync all under '/' with compression enabled 
> excluding the usual /proc /sys etc... so I end up with a 10G zip file on 
> the device. 

rsync does not produce a single archive file. The compression option you 
saw only applies to the "over-the-wire" transport, which would be 
pointless to use when rsyncing between two local file systems. 

You can compress the files before rsyncing them, but you have to be 
careful to use an rsync compatible version of gzip or whatever 
compressor you are using. For example, the Debian version of gzip has 
been patched to support rsync and has an --rsyncable switch. Though the 
consequence of failing to do this is that more data needs to be copied 
(i.e. a while file instead of just the portions that changed), which is 
far less relevant when syncing between two local file systems. 

Putting a file system that supports compression on your USB drive might 
be a better way to go. It'll slow down rsync, as data will need to be 
decompressed as it calculates checksums, but it'll maximize the space on 
the USB drive. 


> Now lets say I want to retrieve /home/user/foo/bar , so 
> would the process be the same as with tar? Only now I am searching 
> through a zip at a faster bit rate? 

Nope, you'd mount the USB drive and access something like: 

/mnt/backup/current/home/user/foo/bar 

or through one of the other snapshot paths if you wanted an older version. 

  -Tom 

-- 
Tom Metro 
Venture Logic, Newton, MA, USA 
"Enterprise solutions through open source." 
Professional Profile: http://tmetro.venturelogic.com/

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 

_______________________________________________ 
Discuss mailing list 
[hidden email] 
http://lists.blu.org/mailman/listinfo/discuss