Posts Tagged ‘hfs+’

SpiderOak Backup Bouncer tests

Wednesday, July 21st, 2010

I really want to like SpiderOak, especially when you consider the following features:

  • Whole cloud de-duplication – All of the data you backup to spideroak, regardless of the source is de-duplicated
  • The ability to share files in your cloud with others
  • ‘Zero-knowledge’ encryption
  • Cross platform client
  • Support of open source

However, I keep finding problems that prevent me from using it as my primary backup software. As with BackBlaze I did some testing with Backup Bouncer v0.2.0 to see how the latest version of SpiderOak (v3.6.9680) fairs with the meta-data that Mac OS X generates. Results follow.

sh-3.2# ./bbouncer verify -d /Volumes/Src ../Dst
Verifying:    basic-permissions ... FAIL (Critical)
Verifying:           timestamps ... FAIL (Critical)
Verifying:             symlinks ...
    stat: ./symlink1: stat: No such file or directory
    FAIL (Critical)
Verifying:    symlink-ownership ... FAIL 
Verifying:            hardlinks ... FAIL (Important)
Verifying:       resource-forks ... 
   Sub-test:             on files ... FAIL (Critical)
   Sub-test:  on hardlinked files ... FAIL (Important)
Verifying:         finder-flags ... FAIL (Critical)
Verifying:         finder-locks ... FAIL 
Verifying:        creation-date ... FAIL 
Verifying:            bsd-flags ... FAIL 
Verifying:       extended-attrs ... 
   Sub-test:             on files ... FAIL (Important)
   Sub-test:       on directories ... FAIL (Important)
   Sub-test:          on symlinks ... FAIL 
Verifying: access-control-lists ... 
   Sub-test:             on files ... FAIL (Important)
   Sub-test:              on dirs ... FAIL (Important)
Verifying:                 fifo ... FAIL 
Verifying:              devices ... FAIL 
Verifying:          combo-tests ... 
   Sub-test:  xattrs + rsrc forks ... FAIL 
   Sub-test:     lots of metadata ... FAIL 

As you can see, SpiderOak fails all of the backup-bouncer tests. Combine this with the password issues I’ve mentioned previously and it looks like SpiderOak still has a ways to go before I can seriously consider using it to house my data.

BackBlaze and metadata

Monday, March 22nd, 2010

Last night I did some testing on BackBlaze with backup-bouncer v0.2.0 to see how well it was preserving the extra meta-data HFS+ is capable of storing. The results were rather shocking:

./bbouncer verify -d /Volumes/Src ~volz/Downloads/Src
Verifying:    basic-permissions ... FAIL (Critical)
Verifying:           timestamps ... FAIL (Critical)
Verifying:             symlinks ... 
    stat: ./symlink1: stat: No such file or directory
    FAIL (Critical)
Verifying:    symlink-ownership ... FAIL 
Verifying:            hardlinks ... FAIL (Important)
Verifying:       resource-forks ... 
   Sub-test:             on files ... ok (Critical)
   Sub-test:  on hardlinked files ... FAIL (Important)
Verifying:         finder-flags ... FAIL (Critical)
Verifying:         finder-locks ... FAIL 
Verifying:        creation-date ... FAIL 
Verifying:            bsd-flags ... 
    stat: ./dir-with-flags: stat: No such file or directory
    FAIL 
Verifying:       extended-attrs ... 
   Sub-test:             on files ... FAIL (Important)
   Sub-test:       on directories ... FAIL (Important)
   Sub-test:          on symlinks ... FAIL 
Verifying: access-control-lists ... 
   Sub-test:             on files ... FAIL (Important)
ls: ./acl-test-dir: No such file or directory
   Sub-test:              on dirs ... FAIL (Important)
Test dir '/Users/volz/Downloads/Src/90-fifo' does not exist
Test dir '/Users/volz/Downloads/Src/95-devices' does not exist
Verifying:          combo-tests ... 
   Sub-test:  xattrs + rsrc forks ... FAIL 
   Sub-test:     lots of metadata ... FAIL

No basic permissions? No timestamps? And no extended attributes? Wow, this means restores from BackBlaze will only get your data back and that you loose all of the hidden data on your files… What does this mean? Well, for example if you have a file that is locked and you restore it, the new file won’t be locked. Examples of other things that get lost: whether or not a file extension is hidden, creation dates, modify dates, symlinks, if a downloaded file hasn’t been opened yet (quarantined), finder comments and where you downloaded an item from. What is the logic here? Is it really that much effort to back this up? Too much space used if you back this up? I wonder how Mozy fares in this test.