More on backup

Hi

I would like to keep this off-topic alive just a little bit more...

> don't forget than some encoding utilities (tar, zip?) uses error
> recovery and redundency, that make archive more secure than individual
> files

I'm using subversion to handle permanent photo storage. There are some
advantages and disadvantages:

On plus side:
1. I do not need to worry about overwriting or deleting original
files. All operations are reversible. Nothings gets permanently
deleted, will remain in svn history.
2. Backup handling is easy. Just copy new svn serverside files to
backup location (most of server-side files are never changed. Easy to
keep the list of changing files that must be copied over)
3. File copies and renames are cheap in mean of server storage.
4. I can safely delete some folders from my working copy if I'm
running out of storage. I can check if all my changes are committed
even if I'm can not connect to my svn server.
5. Sharing work between computers is easy.
6. Changes in files are as cheap as possible on server side storage.
Only differences between original/changed file is stored. (I'm mostly
having raw files + processing instructions - like ufraw xml files)

On minus side:
1. Working copies are twice the size of photo files.
2. No files get permanently deleted. No easy way to reduce the server
storage size
3. I'm still thinking how to fit digiKam into my workflow.
4. File or folder renames means that another client will download all
affected files again. Can get painful if big folders involved.
(luckily I do not rename files often :) )
5. subversion is not optimized for such big binary files. Some
operations are quite slow, seems like too much file coping is going
on. (I never use "svn add" to add new photos. Always "svn import"
outside working copy and then "svn update" in working copy. Well,
maybe recent svn versions are better in this aspect, haven't tested
lately).

As a result I'm still not convinced if the system is good enough. But
it works so far, and I'll keep as long as I get better idea. One
thought is to separate metadata revisions storage from raw photo
storage. But I have not figured out how to to it fluently.

Is anybody else using some version control system to handle photos
(git/cvs/mercurial/???), any hints or thoughts?

I've abandoned idea to use git, as I want to have partial working copy
in laptop with limited HDD storage.

Gert
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Randy Orrison-3]

An alternative to Carbonite is CrashPlan (http://www.crashplan.com/) -
they sound pretty committed to unlimited storage without any bandwidth
throttling.  You can also back up to a friend's PC (or another PC of
your own, anywhere on the internet), and allow friends to back up to
your PC, and if you do that instead of using CrashPlan's cloud storage
the software is free.  The software can also back up to local external
hard drives as well as off-site.  And there's a linux version...

Randy


On 23 February 2011 20:16, Andrew Goodbody <[hidden email]> wrote:

> On 23/02/11 15:45, Paul Verizzo wrote:
>> I mentioned that Carbonite is unlimited storage but it seems that was
>> missed.  It's unlimited.  I have about 170GB on it.  About half is photos.
>
> Hmm, 'unlimited', from the website:-
>
> With your Carbonite subscription you get as much space as you need for
> your backup. However, for exceptionally large backups – 200GB or more –
> backup speed will slow noticeably after the first 200GBs have been
> backed up.
>
> I have about 100GB of jpegs and 240GB of raw files so I'll stick with
> backing up to multiple HDDs, at least one off site at all times, it's
> quicker and cheaper.
>
> Andrew
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users