How to get rid of 12000 snapshots?

[NugentS]

I do use truetool - but there is no mechanism to restore a single container and when I asked I was told that the restore function is not tested well. I am therefore reluctant to trust the process

 

[Patrick M. Hausen]

That's why I use only things that need no or little persistent data and can be setup quickly. Onlyoffice, Truecommand, ... things I toy with. The entire experience is not quite ready for a production setup. Specifically compared to CORE.

But that's really iX' task, not necessarily Truecharts'. If they want to push SCALE as the application platform of choice, and if they think this should provide value with e.g. just the official catalog, there must be a way to snapshot and replicate a single running container/app and start it on some different machine in case the first one breaks.

I can do that with CORE, jails and VMs all easy and reliably.

 

[artlessknave]

GitHub - bahamas10/zfs-prune-snapshots: Remove snapshots from one or more zpools that match given criteria

Remove snapshots from one or more zpools that match given criteria - bahamas10/zfs-prune-snapshots

github.com

you can just say anything older than a month and they will go away

 

[truecharts]

I do use truetool - but there is no mechanism to restore a single container and when I asked I was told that the restore function is not tested well. I am therefore reluctant to trust the process

As stated on the website the restore process has been fully tested a few months ago in a collaborative attempte between HeavyBullets and TrueCharts. Most likely you're basing yourself on out-dated information there. It's well tested and almost all of our staff use it on anglefish.

For BlueFin, due to a few iX-related, bugs, we're still testing things to ensure it works 100%. But the current version is already validated such that it doesn't inherently cause any dataloss.

You might mistake our "it's a best effort tool" warning, with "it might not work". The thing is: It's best effort, because it's mostly not our code (it triggers iX' API's), so we cannot actually give much guarantees ourselves. Because it's simply not ours.

We can say "we tested this and we stand behind it as solid" but that's it. We want to make clear that we're not on the hook if you manage to FUBAR company data because of it.

GitHub - bahamas10/zfs-prune-snapshots: Remove snapshots from one or more zpools that match given criteria

Remove snapshots from one or more zpools that match given criteria - bahamas10/zfs-prune-snapshots

github.com

you can just say anything older than a month and they will go away

To be VERY clear, NEVER EVER run this on ANY sub-dataset of ix-applications.
You're going to inherently break shit you don't want to be breaking, without knowning it.

 

[artlessknave]

To be VERY clear, NEVER EVER run this on ANY sub-dataset of ix-applications.
You're going to inherently break shit you don't want to be breaking, without knowning it.

mmm. likely very true. last time I needed to use it, scale didn't exist yet, and plugins...well plugins barely worked anyway. I haven't really dug much into scale.

 

[Daisuke]

Since the Bluefin release, I updated my Scale build Docker Prune Configuration with the new prune commands.

 

[picklefish]

I had a snapshot task from TrueNAS core that moved over to SCALE and was backing up /ix-applications/. It took up all of my space due to plex trancodes. I cleared the snapshots by making sure the `@auto` was in them with the following command:

Code:

zfs list -t snap | awk '/MySSDs\/ix-applications/ && /@auto/ { printf "zfs destroy %s\n", $1 }'

verify then run

Code:

zfs list -t snap | awk '/MySSDs\/ix-applications/ && /@auto/ { printf "zfs destroy %s\n", $1 }' | sh

the && /@auto/ was critical, so I didn't delete the other snapshots that seem to be automated or something...