11

Say I have a dataset with 100 snapshots and want to rm -rf all folders named "cache" in all snapshots.

I want to actually free up the space, not just hide it away in layers of snapshots, so making a clone and removing from that and then taking a new snapshot doesn't seem to do what I want.

Any semi-automatical way do that? Some wrapping around zfs list -t snapshot, zfs clone, zfs promote, zfs snapshot?

(cross-posting from https://superuser.com/questions/313197 since I see this has more ZFS stuff)

Community
  • 1
Tino Didriksen
  • 243
  • 1
  • 2
  • 7
  • 3
    Please do not crosspost, but wait for your question to be migrated. – Sven Jul 22 '11 at 12:16
  • Also, I am not sure this is at all possible: Snapshots are read-only, and if you use the clone/promote pair, you will reverse the dependency between the cloned snapshot and the "HEAD" dataset, which is likely not what you want. See the doc here: http://download.oracle.com/docs/cd/E19253-01/819-5461/gbcxz/index.html – Sven Jul 22 '11 at 12:33
  • I would wait for migration, but seemed to be a fair amount of ZFS questions on SU as well so I doubted it would be automatically moved...it fits in both places, so I followed a meta guide for how to be nice about cross-posting. – Tino Didriksen Jul 22 '11 at 13:50
  • @TinoDidriksen could you provide a reference to that meta post please? I'd like to see it. Thanks. – nhinkle Jul 22 '11 at 23:19
  • @nhinkle, certainly: http://meta.stackexchange.com/questions/65931/cross-posting-on-stackexchange-sites – Tino Didriksen Jul 23 '11 at 08:28
  • 2
    The post you referenced is not an official policy. There is [an FAQ on MSO](http://meta.stackexchange.com/q/64068/) explaining how to handle questions the user thinks are on topic for multiple sites. To summarize, cross posting is disallowed. If you decide after you post that it would be better elsewhere and you haven't gotten good answers, you can flag it to be migrated or you can delete it and re-ask, but you must tailor the post to the site you're asking on. You reposted the exact same question word-for-word without waiting, which fails the guidelines in both meta posts about cross posting. – nhinkle Jul 23 '11 at 21:34

4 Answers4

16

You could try the following:

  1. Clone the oldest snapshot into a new filesystem (call it fsnew).
  2. Promote the clone (fsnew) to allow you to destroy the snapshot the filesystem is based on.
  3. Remove the offending files.
  4. Create a snapshot of fsnew.

Now foreach snapshot after, rsync with the --inplace flag from the snapshot to fsnew skipping over files you do not want. The --inplace flag reduces the number of writes and allows for smaller snapshots.

  1. Create a snapshot of fsnew.
  2. Destroy the original snapshot.

When this is done, you should have a snapshot on fsnew that corresponds to the snapshots from the original filesystem with the offending files removed.

If you have the space on the drive, you may want to skip the "destroy" command until you have got your script working right.

Bart De Vos
  • 17,761
  • 6
  • 62
  • 81
Michael Boers
  • 161
  • 1
  • 2
  • 1
    You'll also need to pass the `--delete` option to `rsync`, otherwise you will lose deletions occurred between snapshots. Otherwise this is a great idea. – Tobia May 13 '15 at 13:14
9

Snapshots are read-only. If you need those folders gone then you have to delete the whole snapshot.

You can make a backup (with something like tar), excluding the offending folders, then delete the snapshot. Obviously the backup is now in tar, or whatever, format; but at least you still have a backup copy.

Chris S
  • 77,337
  • 11
  • 120
  • 212
  • 2
    The real bummer with this solution is that you now have to store every bit of data *n* times for real, while a snapshot would only store modified blocks. This way, you likely end up with much more space needed than you saved with deleting the caches from the tar files. – Sven Jul 22 '11 at 12:51
  • Dedupe would *help* with that, but your are correct. I'm fairly sure there isn't any way of modifying those snapshots the way he wants though. – Chris S Jul 22 '11 at 12:54
  • I have both gzip-1 compression and dedup on, so copying around identical data only takes up bookkeeping space. But I would of course like some way to avoid copying at all. – Tino Didriksen Jul 22 '11 at 13:55
  • I doubt that in case of multiple tar files of *nearly* the same data dedup would help that much, as adding or subtracting only one byte at the beginning of the file would mean that no block would be identical to another, rendering dedup useless. – Sven Jul 22 '11 at 14:15
  • @SvenW After rereading the question I see he's doing this to try and save space; which my answer really isn't helping with unless he moves the tar files off the computer, which he could just export the snapshots anyway. Sounds like he's stuck all around. – Chris S Jul 22 '11 at 14:35
  • So the only way to have mutable versioned backups with ZFS is to not use the snapshot (and thus the clone) feature. Good ol' named folders, then...at least dedup reduces the overhead greatly. That is annoying. I wish one could create a clone of a dataset without the intermediate snapshot. – Tino Didriksen Jul 24 '11 at 08:42
1
  1. Destroy the original snapshot.

You cannot destroy orig snapshot after promote action. Only if so destroy parent dataset.

example (after promote clone).

zfs destroy media1/cheers/backup-auto-20190530.2105-2y-clone@auto-20190530.2105-2y

cannot destroy 'media1/cheers/backup-auto-20190530.2105-2y-clone@auto-20190530.2105-2y': snapshot has dependent clones

use '-R' to destroy the following datasets:

media1/media/backup@auto-20190531.1622-2y

media1/media/backup

zfs destroy media1/media/backup@auto-20190531.1622-2y

zfs destroy media1/cheers/backup-auto-20190530.2105-2y-clone@auto-20190530.2105-2y

cannot destroy 'media1/cheers/backup-auto-20190530.2105-2y-clone@auto-20190530.2105-2y': snapshot has dependent clones

use '-R' to destroy the following datasets:

media1/media/backup

After that "funny" operation, I must make next ones

zfs snapshot media1/media/backup@1

zfs send media1/media/backup@1 | pv | zfs receive media1/media/backupnew

zfs destroy media1/media/backup@1

zfs destroy -R media1/media/backup

zfs rename media1/media/backupnew media1/media/backup

OR invert promote one. zfs promote media1/media/backup and after it delete clone anuway, because you will be have a big snapshot in src place))

Only rsync/backup can help here.

Дмитрий Мышков
  • 11
  • 2
-3

The ZFS snapshots for a particular ZFS filesystem can be found under the .zfs/snapshotsdirectory in the root of the filesystem. You should be able to write a script that traverses this folder and rm's the files that you need, which should delete it from the snapshots themselves.

growse
  • 7,830
  • 11
  • 72
  • 114