Bug 1208404

Summary:	[Backup]: Behaviour of backup api in the event of snap restore - unknown
Product:	[Community] GlusterFS	Reporter:	Sweta Anandpara <sanandpa>
Component:	glusterfind	Assignee:	Aravinda VK <avishwan>
Status:	CLOSED CURRENTRELEASE	QA Contact:	bugs <bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	mainline	CC:	avishwan, hchiramm, khiremat
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	glusterfs-3.7.0	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1224102 (view as bug list)		Environment:
Last Closed:	2015-05-27 08:08:56 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:
Bug Depends On:
Bug Blocks:	1186580, 1224102

Description Sweta Anandpara 2015-04-02 07:55:10 UTC

Description of problem:

This is to ascertain what should be the right way of going about, when a user has backup tool running along with snapshots. 

Say a user has snapshots getting created at time stamps t1, t2, t3 .. 
At timestamp t4, a backup is taken using glusterfind api. This results in all the changes to get synced until t4. The status file $SESSION_DIR/status is updated with t4. IF the user at this point has a requirement to go back in time, he/she restores file(s) at timestamp t2. Now the changed file(s) would have the timestamp t2, which will NOT get recorded as 'changed files' in the next run of glusterfind pre command (as t2 < t4).

Possible ways to resolve:

1) We could ensure that 'snapshot restore' restores/updates the status file present in $SESSION_DIR, with the timestamp of the restored snapshot (in the above e.g., t2)

2) We could have clear warnings displayed to let the user know that the backup destination is not going to stay up-to-date, when he/she tries to run snapshot restore, unless a --full backup is done

3) We could update our documentation stating that caution would have to be exercised in case a user is using both backup as well as snap restore.


Version-Release number of selected component (if applicable):
Gluster 3.7 upstream nightly glusterfs-3.7dev-0.852.git3feaf16.el6.x86_64

Comment 1 Aravinda VK 2015-05-09 14:33:30 UTC

This is not a bug, but needs documentation update.

1. following a snap restore, take a full backup to ensure the backup catalog/db stays in step the the volume state
2. expire backup copies taken between the original date of the snap and the restore date

Moving this Bug to MODIFIED state.

Comment 2 Aravinda VK 2015-05-27 08:08:56 UTC

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.