Interesting Techniques

Getting Technical

Dirvish

Dirvish takes a similar approach to rsnapshot (see below), but differs in details. A backup regime implemented for one would be difficult to convert to the other.

http://wiki.dirvish.org/DirvishUsage

rnapshot

rsnapshot for Linux etc

rsnapshot is tested on many UNIX-like OS

• The philosophy behind rsnapshot is tha backups happen regularly and reliably only if fully automated
  • rsnapshot handles the "how, what & where"
  • cron handles the "when"
• but wait, there's more
  • speed & space efficiency approach that of incremental backups
  • restores files as easily as from stand-alone backup
• best installed from your Operating System's media/repositories - alternatively
  • http://www.rsnapshot.org/downloads.html
• essential - read their HOWTO

Suggested approach:

1. get installed, configured and working
   • a minimal data set can be configured for test purposes by # ing out many directories listed in the rsnapshot.conf script
   • similarly, a small, surplus hard drive can serve as a test target medium - either internal to PC or via USB interface
     • NB - the default script puts the backup set on a directory of the system disk
     • whilst the simplest, first-stage test that is not a reliable long-term approach
   • backing up manually to an external USB/eSATA drive is a simple, second-stage test
     • could also suffice for data that changes infrequently and is not particularly valuable
2. follow HOWTO to automate backups to "local" eg USB drive
3. follow HOWTO to backup to LAN or remote drive

Storage Requirements:

Test/prototype impmentations of rsnapshot/Dirvish could be done from minimal data sets to any available storage media. It is important to accurately estimate the long term storage requirements for production implementations, considering that these tools:

• do not compress the backup
  • nor is it practical to do so using supporting tools
• make extensive use of the filesystem function of "hard-links" for space & time efficiency
  • it is impractical to later copy/clone file sets containing multiple hard-links to larger media
• run "du" or use a GUI file manager to calculate the size of the data set to be backed up
  • have a target medium at least twice that size for data having low rate of change (many home systems ?)
  • use yet larger target medium if frequent backups or changes in data are anticipated.
• if multiple backup sets are required (eg local plus off-site)
  1. prepare & test a working script ie rsnapshot.conf for one target medium
     • the backup is readily mountable
     • it should immediately be readable (being uncompressed)
     • its lower level directories should accurately reflect that of the source data set
  2. give the tested script a unique name, related to the target
  3. make a copy of the script to another name
     • make minor modifications to suit the other target medium
       • alter "snapshot_root" to reflect possibly different mount point
       • set "no_create_root 1" for USB medium
     • test with the other medium
  4. routinely run each script whilst its specific target medium is mounted

Similar considerations apply to Dirvish

rsnapshot for MacOSX

• might be available for later versions - see:

http://www.rousette.org.uk/blog/archives/backups-rsync-and-rsnapshot/

rnapshot for Windows

• probably not feasible
  • because Windows filesystems do not provide the required functions
• cwRsync goes part way

http://www.rsync.net/resources/howto/windows_rsync.html

-Rpeters13:25, 24 August 2012 (EST) --

Strictly for Geeks

--Rpeters14:37, 26 August 2012 (EST)