Re: Backup compaction optimization in a block-level replication environment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Food for thought.  Maybe instead of having one "%SHARED" backup, having one "%SHARED.foo" backup per top-level shared folder would be a better implementation?  I haven't seen shared folders used much in practice, so it's interesting to hear about it.

Looking at your own data, if you had one "%SHARED.foo" backup per top level shared folder, would they be roughly user-sized pieces, or still too big?  If too big, how deep would you need to go down the tree until the worst offenders are a manageable size?  (If I make it split shared folders like this, maybe "how-deep-to-split-shared-folders" needs to be a configuration parameter, because I guess it'll vary from installation to installation.)

For my data, %SHARED.foo would be the perfect granularity level. Each foo is a shared email address like "sales" or "accounts" and it gets about as much traffic as a user account does.  (Two months ago when we were on Exchange, they _were_ user accounts.)

foo also includes "#calendars" and "#addressbooks" on my server so there are weird characters to deal with.

--
Deborah Pickett
System Administrator
Polyfoam Australia Pty Ltd
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus




[Index of Archives]     [Cyrus SASL]     [Squirrel Mail]     [Asterisk PBX]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux