[Unison-hackers] Quick poll: Who uses backup / backups?

[James O'Brien]

Personally I like having the backup files easily visible in the same 
directory.  But I can see how others would like .snapshot directories 
or a central back directory.  Right now, the central -vs- in-place 
options use totally separate code with different options.  It's ugly.  
The backupS (w/ an S) code could be fairly easily modified to make the 
location of the backup files a configurable option.  The files could be 
located in a directory that can be relative to the unison ROOT, the 
filesystem root, or the directory containing the file. If a central 
directory is used then some care must be taken to prevent collisions.  
(By the way, I don't think the current backup [with no S] option does 
this collision avoidance... which in my opinion makes it inherently 
broken.)

The suggestion to gzip backup files would make a great option.  In some 
cases you would not want to, but quite often it would be useful.  It 
would be a fairly easy to add option I think.

Also, the current version of the backupS option has a feature to 
automatically delete backup files older than some age.  It checks when 
it does sync'ing so if you sync regularly there is no need for a 
separate cron job to delete them.  (But if you like to run cron jobs, 
then you could get the gzip feature by having a cron job that looks for 
backup files and zips them... I think the problem of ziping a 
backupfile as it is being written is zero because backup files are just 
original files that have been renamed.)
		
			- James




On Jun 6, 2005, at 1:49 PM, Derek Rayside wrote:

> I use the centralized backup facility.  I run a cron job to delete 
> files
> out of this directory that are more than 90 days old.  Otherwise the
> central backup directory can grow quite large:  it used to get into the
> 10-20gb range before I would clean it manually, but now the cron job
> usually keeps it under 5gb.
>
> Of course, I wouldn't want to delete my working files that are over 90
> days old.  But if the names were sufficiently unique then it wouldn't 
> be
> too hard to make the cron job delete the backups and not the real 
> files.
>
> Have you considered make a .snapshot or .backup directory inside of 
> each
> directory?  We have a file server here that puts a .snapshot directory
> inside of each directory.  It contains four hourly snapshots and a 
> week's
> worth of nightly snapshots, plus four weekly snapshots.  The server 
> does
> this via some copy-on-write facility.  Users are pretty happy with
> retrieving old version of their files this way, and it doesn't clutter 
> up
> their working directories.
>
> My personal preference is to have a .backup/.snapshot directory inside 
> of
> each directory.  Advantages:
> - easier to retrieve backups than from a centralized backup directory
> - doesn't clutter up working directories like .bak files do
> - backups move around when directories get renamed
> - still easy to write a cron job to delete old backups without worrying
>   about accidentally clobbering the real files
>
> While we're on the subject of the backup feature, it might also be 
> nice to
> have Unison run a compression program (eg, gzip, bzip2, infozip, 
> whatever)
> on the backup files.  They are rarely accessed, and can grow to 
> consume a
> lot of space.
>
> Thanks for writing such a great piece of software.
>
> Derek.
>
>
> On Mon, 6 Jun 2005, Benjamin Pierce wrote:
>
>> We're in the middle of some reimplementation work on the merge
>> functionality, and as part of this we're considering simplifying and
>> rationalizing the backup functionality.
>>
>> At the moment, Unison provides two different preferences for 
>> controlling
>> backups: "backup", which keeps backup copies in the same directory as 
>> the
>> current version of the file, and "backups", which maintains a 
>> centralized
>> tree of backup files under the .unison directory.
>>
>> We're considering removing the centralized mechanism and keeping just 
>> the
>> simpler "backup" functionality (and, at the same time, giving the 
>> user more
>> control over how these backup files are named).
>>
>> If you would be seriously inconvenienced by this change, can you 
>> please
>> either drop me an email or (if you have a comment of general 
>> interest) post
>> a message here?
>>
>>      - Benjamin
>>
>>
>>
>> _______________________________________________
>> Unison-hackers mailing list
>> Unison-hackers at lists.seas.upenn.edu
>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>>
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>

--
James F. O'Brien                      Assistant Professor
EECS, Computer Science Division       job at cs.berkeley.edu
University of California, Berkeley    www.cs.berkeley.edu/~job