I’ve got two machines that I need to backup, an iMac running OS X 10.0.3 and a Dell running Windows XP. The iMac is the primary home machine with about 13Gb of pictures, music, documents, etc, etc. The Dell is more of a development machine with about 1Gb of files to backup. I wanted a backup medium that I could use on both machines. I’ve never been a big fan of tape backup solutions. They’re just too expensive and difficult to use in a home environment. Because I don’t have a huge amount of stuff to backup I decided to go with an external harddrive.
They’re cheap, easy to setup and I could use it on both machines. In the end I went for a. It’s a little bit more expensive then a basic harddrive and enclosure but not so much that it turned me off.
I went with the Premium version because it had the Firewire connection. If I were buying it again I don’t think I’d bothered with the Premium edition because when all you’re backing up is thousands of relatively small files it’s the processing time that slows the process down not the speed of the connection to the harddrive. With the medium chosen I then had a look around for some backup software. I wanted something that was opensource and cross platform so that I only had to learn how to use one program. There’s very little out there that’s easy to understand and use.
The basic programs just don’t instill any confidence while the feature rich programs are just too complicated and more suited to business environments. The most popular program seems to be. The problem with AMANDA is that it’s far too complicated for a simple home backup solution (in my mind anyway). The program I finally settled for was.
It’s not too complicated and has all the basic features I need, it’s open source, it’s cross platform and it has a user community. Something that I sort of forgot about up to this point was the filesystem to use on the external harddrive. If you’re only backing up a Windows machine then I suggest you format your target backup drive as NTFS. If you’re on Mac then use HFS and if you’re on Linux use ext3 or whatever you prefer. If however you want to be able to see the same partition from both Windows and Mac (like I do) then you MUST use FAT32. The reason for this is because OS X cannot write to NTFS (only read) and Windows certainly cannot write or read HFS.
Rdiff-backup-users Re Testsuite For Mac
The only common filesystem that the two OSes can write to is FAT32. The only potential problem with this is that FAT32 only supports files up to 4Gb in size. For me this isn’t a problem but if you have a lot of videos you may find that some exceed this limit. If this happens then you could just create two partitions on the external harddrive, one HFS for your Mac backups and one NTFS for your Windows backups. You won’t be able to see the HFS partition from Windows but if that’s not a problem for you then this might be the best approach all round.
The other drawback with FAT32 is that Windows will only allow you to create a partition that’s 32Gb in size. The strange thing is that Windows can reference a FAT32 partition that’s up to 2Tb in size. To create a partition greater that 32Gb WD have a tool for the My Book called the. There’s probably generic tools out there that will do this for any harddrive. Rdiff-backup on Mac OS X The first machine I backed up was the iMac.
Because I might be restoring onto a completely clean machine I created a folder on the external harddrive with all the software that’s needed to install and run rdiff-backup. Into this directory I put. (I got the patch from this useful post ) Installing librsync on Mac OS X.
Tar -xzvf rdiff-backup-1.1.5.tar.gz cp fsabilities.py.patch rdiff-backup-1.1.5/rdiffbackup cd rdiff-backup-1.1.5/rdiffbackup patch.
This defines the data structure for the.cabal file format. There are several parts to this structure. It has top level info and then, and sections each of which have associated data that's used to build the library, exe, or test. To further complicate things there is both a and a.
This distinction relates to cabal configurations. When we initially read a.cabal file we get a which has all the conditional sections. Before actually building a package we have to decide on each conditional. Once we've done that we get a. It was done this way initially to avoid breaking too much stuff when the feature was introduced. It could probably do with being rationalised at some point to make it simpler. Fields:::::::::::::::: (, ):::::::: :: A one-line summary of this package:: A more verbose description of this package:::: (, ) Custom fields starting with x-, stored in a simple assoc-list.:: :: The version of the Cabal spec that this package description uses.
For historical reasons this is specified with a version range but only ranges of the form = v make sense. We are in the process of transitioning to specifying just a single version, not a range.:::::: :: :: :::: ::. Constructors calls Distribution.Simple.defaultMain calls Distribution.Simple.defaultMainWithHooks defaultUserHooks, which invokes configure to generate additional build information used by later phases. Calls Distribution.Make.defaultMain uses user-supplied Setup.hs or Setup.lhs (default) a package that uses an unknown build type cannot actually be built. Doing it this way rather than just giving a parse error means we get better error messages and allows you to inspect the rest of the package description.
Constructors Test interface 'exitcode-stdio-1.0'. The test-suite takes the form of an executable. It returns a zero exit code for success, non-zero for failure. The stdout and stderr channels may be logged. It takes no command line parameters and nothing on stdin. Test interface 'detailed-0.9'.
The test-suite takes the form of a library containing a designated module that exports 'tests:: Test'. A test suite that does not conform to one of the above interfaces for the given reason (e.g. Unknown test type). Information about the source revision control system for a package. When specifying a repo it is useful to know the meaning or intention of the information as doing so enables automation. There are two obvious common purposes: one is to find the repo for the latest development version, the other is to find the repo for this specific release.
The ReopKind specifies which one we mean (or another custom one). A package can specify one or the other kind or both. Most will specify just a head repo but some may want to specify a repo to reconstruct the sources for this package release. The required information is the which tells us if it's using, for example. The and other details are interpreted according to the repo type.
Fields:: The kind of repo. This field is required.:: The type of the source repository system for this repo, eg. This field is required.:: The location of the repository. For most s this is a URL. This field is required.:: can put multiple 'modules' on one server and requires a module name in addition to the location to identify a particular repo. Logically this is part of the location but unfortunately has to be specified separately. This field is required for the and should not be given otherwise.:: The name or identifier of the branch, if any.
Many source control systems have the notion of multiple branches in a repo that exist in the same location. For example and use this while systems like use different locations for different branches. This field is optional but should be used if necessary to identify the sources, especially for the repo kind.:: The tag identify a particular state of the repository.
This should be given for the repo kind and not for kind.:: Some repositories contain multiple projects in different subdirectories This field specifies the subdirectory where this packages sources can be found, eg the subdirectory containing the.cabal file. It is interpreted relative to the root of the repository.
This field is optional. If not given the default is '.' Ie no subdirectory.