zfsnap2 does not delete stale snapshots about zfsnap HOT 9 CLOSED

@chlarsen This is because snapshots with a prefix aren't considered for deleting unless you're searching for them.

So the correct command would be:

zfsnap destroy -rnv -p 'server-hourly- server-daily- server-weekly- server-monthly-' 

This behavior, to a certain extent, doesn't make a whole lot of sense, as it treats a lack of a prefix as a prefix. And at very least, the documentation should be more clear. I'll take a look how zfsnap 1.x behaved and see if this is a change in behavior.

---Alex

from zfsnap.

In zfSnap 1 to delete snapshots with prefix you had to specify that prefix on command line.

As far as I remember it as like:

zfSnap -d -p foo_ -p bar_ -p baz_

This would delete snapshots without prefix
and snapshots with foo_, bar_, baz_ prefixes

from zfsnap.

Thanks Alex and Aldis, let me try this in a few minutes. I will revert
asap. Hugely appreciated.

Chris

from zfsnap.

Hi Alex,

I am afraid, it does not do anything (even without the "-n" :-) ).

When I issue the command, it returns to the prompt within a split second

• which is way too fast for the number of snapshots that have
  accumulated by now.

Is there any way I can log this, to see what is happening? The "-v" does
not give anything, either.

Weird...

Chris

from zfsnap.

Dear Alex, dear Aldis,

I got it working - a slight modification of your recommended command:

fsnap destroy -p "backup-hourly-" -p "backup-daily-" -p "backup-weekly-"
-p "backup-monthly-" -p "backup-yearly-" -rn zroot

The quotation marks have to frame the prefixes, which have to come with
a "-p" each, like in good ole' version 1.

Thanks a million for putting me back on track,

Chris

On 08/09/16 11:31, Alex Waite wrote:

@chlarsen https://github.com/chlarsen This is because snapshots with
a prefix aren't considered for deleting unless you're searching for them.

So the correct command would be:

|zfsnap destroy -rnv -p 'server-hourly- server-daily- server-weekly-
server-monthly-' |

This behavior, to a certain extent, doesn't make a whole lot of sense,
as it treats a lack of a prefix as a prefix. And at very least, the
documentation should be more clear. I'll take a look how zfsnap 1.x
behaved and see if this is a change in behavior.

---Alex

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#81 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACvwTfD-WYv3u59rmHWkZnsFH7VMtKKsks5qn8f6gaJpZM4J3GtB.

Dr Christoph H. Larsen
synaLinQ
296/33 Lương Định Của, Ngọc Hội 2, Vĩnh Ngọc
Nha Trang, Khánh Hòa, Việt Nam
Mobile: +84-98-9607357 (Vietnam)
+254-776-588224, +254-701-279511 (Kenya)
+256-778-121305 (Uganda)
+49-176-96456254 (Germany)
Fax: +49-231-292734790
E-mail: [email protected]
Skype: christoph.larsen

from zfsnap.

@graudeejs Thanks for the clarification. :-)
@chlarsen Glad to hear it's working for you. I'm a bit surprised that specifying multiple prefixes in one call doesn't work. I'll look into that.

Closing.

---Alex

from zfsnap.

@aqw I'm not suprised, One flag expects one prefix, after then it "thinks" that next argument is zpool name.

At least v1 was working this way, since argument parsing was done in generic/common loop

from zfsnap.

@graudeejs But they were quoted going in, and should be treated as one unit. If it though it was a zpool name, it should have thrown a Fatal error at some point...

---Alex

from zfsnap.

Yes, your right about that. Didn't notice that.

In that case nothing matched (there was no such prefix)

from zfsnap.