Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1086497

Summary:	[RFE] - Upon snaprestore, immediately take a snapshot to provide recovery point
Product:	[Community] GlusterFS	Reporter:	Paul Cuzner <pcuzner>
Component:	snapshot	Assignee:	bugs <bugs>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	mainline	CC:	bugs, rkavunga
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-10-16 04:50:15 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Paul Cuzner 2014-04-11 02:36:46 UTC

Description of problem:

The planned snap restore process, rolls a volume back to a specific snapshot - but in doing so removes that snapshot as a future recovery point. It is common for snaprestore to be used as a recovery mechanism when programmatic errors in application(s) cause data issues. The reality is that when the application is 'fixed', it sometimes isn't - in this scenario returning to the same point a second time is simply not be possible with current snapshot plans.

A snapshot restore should not eliminate the snapshot used as a recovery point for future rollbacks. It is therefore requested that as part of the restore process, a snapshot is taken to ensure the point in time for future recoveries is maintained. It is also recommended that this 'replacement' snapshot takes the name of the original snapshot that was lost by the snapshot restore operation. Keeping the name - especially if it uses a timestamp will help admins understand the actual recovery point they are returning too.

This request is the result of a conversion of gluster-devel - April 9th 2014, and a RFE requested by Rajesh Joseph.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Niels de Vos 2014-11-27 14:45:20 UTC

Feature requests make most sense against the 'mainline' release, there is no ETA for an implementation and requests might get forgotten when filed against a particular version.

Comment 2 Mohammed Rafi KC 2018-10-16 04:50:15 UTC

This RFE will be tracked as a git hub issue https://github.com/gluster/glusterd2/issues/1285 and will be considered to fix in glusterd2