[Bugs] [Bug 1208404] New: [Backup]: Behaviour of backup api in the event of snap restore - unknown
bugzilla at redhat.com
bugzilla at redhat.com
Thu Apr 2 07:55:10 UTC 2015
https://bugzilla.redhat.com/show_bug.cgi?id=1208404
Bug ID: 1208404
Summary: [Backup]: Behaviour of backup api in the event of snap
restore - unknown
Product: GlusterFS
Version: mainline
Component: glusterfind
Assignee: bugs at gluster.org
Reporter: sanandpa at redhat.com
QA Contact: bugs at gluster.org
CC: avishwan at redhat.com, khiremat at redhat.com
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
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the Bugs
mailing list