Updates for apps sorted by size

[privsec]

@marcusquinn I get it, totally. And I plan on it.
But the original issue remains.

Even If I switch services, without versioning I have nearly 6TB of data being stored.

I want to know where that's from so I can prune as needed.

[subven]

@privsec said in Updates for apps sorted by size:

I want to know where that's from so I can prune as needed.

Again...where do you get the 6TB number from? You can search through your backup files by domain like app_domain.com* to figure out what app consumes how much within your backup.

So in my case, 25GB compressed appdata ending up as 275GB in my backup. 1 backup per day and 7 days retention. Keep in mind that another another full mirror is stored in the backups "storage" folder under different naming.

Because you have one big app (the light blue one...is it Nextcloud?) with lots of data in it, this could be the reason for your backup size. Also consider using RSYNC if you have lots of huge files that don't change that often.

[jdaviescoates]

@privsec said in Updates for apps sorted by size:

Even If I switch services, without versioning I have nearly 6TB of data being stored.

I bet you wouldn't.

And as others have explained, just do tarball backups one by one on a new backup provider and then you'll know how much space each app's backup takes up in reality.

[privsec]

@subven

@privsec said in Updates for apps sorted by size:

This is partly why I want to know what apps have what amount of space in backups.

I have 5.6 tb of data in wasabi, but I have no idea as to why its that high

It does look like my backups in cloudron do not list all the backups in Wasabi

MY thought process is that this is an issue/bug

[privsec]

@privsec said in Updates for apps sorted by size:

@subven

Disk Utilization

Encryption settings

@jdaviescoates said in Updates for apps sorted by size:

@privsec said in Updates for apps sorted by size:

Even If I switch services, without versioning I have nearly 6TB of data being stored.

I bet you wouldn't.

And as others have explained, just do tarball backups one by one on a new backup provider and then you'll know how much space each app's backup takes up in reality.

I am currently using tarball for backups, am I missing something?

[jdaviescoates]

@privsec said in Updates for apps sorted by size:

I am currently using tarball for backups, am I missing something?

Yes you are not listening to everyone saying the same thing:

Wasabi does all sorts of dodgy jiggery pokery which is increasing your storage usage.

Just start experimenting with another backup provider to see what your actual storage usage should be.

[privsec]

@jdaviescoates
Ok, I guess I am just misunderstanding folks. I will post results with a different provider when possible.

[jdaviescoates]

@privsec I get that you want to understand what was/ is actually going on, but from where I'm sitting you spending time investigating that would just be you throwing more resources down the wasabi hole

[privsec]

@jdaviescoates I have switched to idrive just now and doing a backup. My jellyfin has all the media storage within the app container (discovered this as the backup for jelly was taking forever) I thought it was in a volume.

Now I will be looking at migrating this data to a volume.

[jdaviescoates]

@privsec said in Updates for apps sorted by size:

My jellyfin has all the media storage within the app container (discovered this as the backup for jelly was taking forever) I thought it was in a volume.

Sounds like you've likely found the main culprit!

[marcusquinn]

@privsec Good stuff, yes, Wasabi is storing duplicates of backups for 90 days after each backup, hence you are multiplying your storage use with them, even if you have backups being purged, they are showing that as still stored for another 90 days thereafter. Bit of their bullshit really, as they cannot recover deleted files, even a minute after.

[robi]

@marcusquinn and they charge for it?

[marcusquinn]

@robi Yeah. I can't recall any other S3 services doing this, but maybe they got the idea from somewhere, or maybe it's just their way of making their headline pricing appear more competitive and trying to protect revenue volatility. If it were me, I really don't think this could make as much difference to their bottom-lines as actual customer satisfaction and goodwill, because for all they might gain, I expect they lose as much in bitterness and loss of recommendation-level happiness.

[robi]

@marcusquinn their support should be able to tell you knowing how the back end works. Some systems are highly optimized for injest, but less for garbage collection, which can be deferred since it causes injest disruption. If they do this at 90day intervals, that's a pretty poor architectural set of choices.

If it's not usable, it should not be charged or passed on to the customer. They'd be smarter to hide it with larger customers where it matters less than smaller ones where it's very obvious.

[jayonrails]

@marcusquinn said in Updates for apps sorted by size:

Paid $20 for 5TB for a year with idrive.com/e2 sign-up offer.

I would like to try it. What settings do I have to appl to Cloudron backup settings to get it up and running?

[marcusquinn]

@jayonrails The generic "S3 API Compatible v4" is what's used for anything not in that list.

[jayonrails]

@marcusquinn thanks a lot, I will try it!

[jayonrails]

@marcusquinn works perfectly for me. Thanks for your tips!

[marcusquinn]

@jayonrails Cool. I recommend sticking to Tarball. Faster and takes up less space overall.