Comment 7 for bug 1680683

So the bulk of the backup is just that you have a large 'blobstore' which
is all of the charms, resources, etc that you have deployed.

Offhand I can't say whether that is active charms (currently in use) or
historical. I know we've looked at auto-pruning charms that are no longer
in use (as long as it would be available from somewhere like the charm
store).

One major caveat is that if these are "local" charms, we really don't know
if you have a copy if you ever had to go back to a version that isn't your
current version. So I don't think we could prune automatically. That said,
we could provide commands to manage/cleanup your cached charm revisions
manually.

You might have a feel for what you have currently running, and how large
they are.

John
=:->

On Wed, Apr 12, 2017 at 5:12 AM, Paul Gear <email address hidden> wrote:

> @jameinel: The updated sizes script didn't work on a slave; the problem
> is earlier in the code than your change - it fails on calling
> db.getCollectionNames().
>
> Here are the "show databases" results for this environment:
>
> juju:PRIMARY> show databases
> admin 0.000GB
> backups 13.161GB
> blobstore 6.017GB
> juju 0.541GB
> local 0.545GB
> logs 0.344GB
> presence 0.199GB
>
> Here are the sizes2 results for the individual databases:
> https://pastebin.canonical.com/185602/
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1680683
>
> Title:
> Poor "juju create-backup" performance
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1680683/+subscriptions
>