This is a question I'm interested as well. Right now, I'm using cephfs-snap from the storage tools project and am quite happy with that. I made a small modification, but will probably not change. Its a simple and robust tool. About where to take snapshots. There seems to be a bug in cephfs that implies a recommended limit of the total number of snapshots to not more than 400. Hence, taking as few as possible (i.e. high up) seems sort of a must. Has this changed by now? In case this limit does not exist any more, what would be best practice? Note that we disabled rolling snapshots due to a not yet fixed bug; see this thread: https://www.mail-archive.com/ceph-users@xxxxxxxxxxxxxx/msg54233.html Best regards, ================= Frank Schilder AIT Risø Campus Bygning 109, rum S14 ________________________________________ From: ceph-users <ceph-users-bounces@xxxxxxxxxxxxxx> on behalf of Robert Ruge <robert.ruge@xxxxxxxxxxxxx> Sent: 17 July 2019 02:44:02 To: ceph-users@xxxxxxxxxxxxxx Subject: cephfs snapshot scripting questions Greetings. Before I reinvent the wheel has anyone written a script to maintain X number of snapshots on a cephfs file system that can be run through cron? I am aware of the cephfs-snap code but just wondering if there are any other options out there. On a related note which of these options would be better? 1. Maintain one .snap directory at the root of the cephfs tree - /ceph/.snap 2. Have a .snap directory for every second level directory /ceph/user/.snap I am thinking the later might make it more obvious for the users to do their own restores but wondering what the resource implications of either approach might be. The documentation indicates that I should use kernel >= 4.17 for cephfs. I’m currently using Mimic 13.2.6 on Ubuntu 18.04 with kernel version 4.15.0. What issues might I see with this combination? I’m hesitant to upgrade to an unsupported kernel on Ubuntu but wondering if I’m going to be playing Russian Roulette with this combo. Are there any gotcha’s I should be aware of before plunging into full blown cephfs snapshotting? Regards and thanks. Robert Ruge Important Notice: The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete it and any attachments immediately and advise the sender by return email or telephone. Deakin University does not warrant that this email and any attachments are error or virus free. _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |