hg as backup solution

[Vadim Lebedev]

Thomas Arendsen Hein wrote:

>* Vadim Lebedev <vadim at mbdsys.com> [20050517 17:05]:
>  
>
>>It just dawned on me that if I symlink .hg  to   smb or nfs mounted dir 
>>i have
>>very neat backup solution....
>>    
>>
>
>Some problems:
>
>1. You don't have the ability to throw away old versions.
>
>   Possible solution:
>   Cycle the .hg directory every week/month/year/whatever.
>  
>
Another possible solution is to implement hg prune command with obvious 
semantics

>2. If something goes wrong during the backup process, the backup
>   (old *and* new) might get corrupted.
>
>   Possible solution:
>   Use two different backup servers, where only one server will be
>   accessed at any time by all computers doing backup this way.
>
>3. A harmful program or user (intentionally or by mistake) probably
>   has full write and delete access to the backup server(s), so the
>   repository is not safe here.
>
>   Possible solution:
>   Use hg push protocol with servers having an immutable history.
>  
>

 

>4. You can't take a backup to another safe place to be protected
>   from fire, theft, etc.
>
>   Possible solution:
>   Make the second backup server located far away from the first.
>
>Sounds like having a removable media solution would be easier to
>make bullet proof (I think backups have to be!), but a solution
>using hg would be much better than the often used rsync solution.
>
>Thomas
>
>  
>
Actually i thought about double-staged solution...
Fisrt  symlink .hg over lan to the primary server and do hg commit, and 
then do a hg push  from the primary server to the secondary server(s)...