Re: bandwidth and space required to sync a basic mirror

On Tue, 03 Jun 2014, anarcat wrote:
> One of the things I am wondering is if it is worthwhile to keep a
> private mirror running for clusters that have lots of machines and want
> to spare the bandwidth costs yet do not want to offer the public hosting
> commitment...

Well, the bandwidth requirements to keep a *stable* mirror up-to-date are
small, so the payoff of a private mirror for stable and oldstable is rather
good.

For unstable, it depends.  On a private mirror, you don't have to mirror
what you won't need and you don't even have to keep the mirror up-to-date
daily: as long as you list public mirrors as well as your private mirror
(list your private mirror *first*) on the client's source.list, missing and
outdated packages will be fetched from the public mirrors.   It really
depends on how the mirror will be used.

To ease my DD work, I do keep a private mirror of the binaries for i386 and
amd64 sans debug section (updated three times a week), and a source package
mirror (updated no more than once a week, usually once a month).  Being able
to build chroots and run pbuilder while offline is great.  Having it work
lightning fast fetching from local disk and installing to a tmpfs is a real
timesaver, as well.

So, yes, I think it is worthwhile to keep *partial* private mirrors when
something like apt-proxy won't cut it.

I've found that "debmirror", even if it is currently full of cowebs and in
need of some upstream-style love, really helps building partial mirrors and
keeping them up-to-date.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh