I would think that case 2 "unregistered consumer" is likely to be more workable. A couple of questions; 1. How do we get the start time for the incremental run? Are we holding it within changelog for example, or should the script record the last run time or do you think this sould be determined by the backup server? My vote is changelog :) 2. If it's an incremental run, the changelog components being active across the nodes is mandatory isn't it? If so, will there be a glusterbackupapi status to confirm that the cluster is 'ready'? The script can call this, and abort if necessary. 3. TS consistency is key - so make this part of the status check - if the nodes are not time consistent, simply declare not ready and force the abort. 4. on the invocation "glusterbackupapi inc <host> <volume> <STARTTIME> <ENDTIME> --out-file=out.txt", could endtime default to current time? Generally the time of invocation is going to be the cut off anyway. 5. what's the granularity of the changelog - volume only? This may change the way solutions are designed. ie. if a customer want to backup home, group and profiles concurrently the design may have home,group and profiles thinp volumes instead of a single volume with quota for example. The other thing to remember is that most backup products provide different backup levels a) full b) differential-incremental and c) cumulative-incremental (TSM is the exception). Our capability is therefore not a 100% match, since we will miss the cumulative-incremental option. I don't think this is widely adopted though but it's worthwhile documenting. TSM is a special case. With TSM, after the first backup, it is incremental forever. Cheers, PC ----- Original Message ----- > From: "Aravinda" <avishwan@xxxxxxxxxx> > To: "gluster Devel" <gluster-devel@xxxxxxxxxxx> > Cc: "Ajeet Jha" <ajha@xxxxxxxxxx>, "Kotresh Hiremath Ravishankar" <khiremat@xxxxxxxxxx>, "Nagaprasad Sathyanarayana" > <nsathyan@xxxxxxxxxx>, "Paul Cuzner" <pcuzner@xxxxxxxxxx> > Sent: Friday, 19 December, 2014 6:08:20 AM > Subject: GlusterFS Volume backup API > > Hi, > > > Today we discussed about GlusterFS backup API, our plan is to provide a > tool/api to get list of changed files(Full/incremental) > > Participants: Me, Kotresh, Ajeet, Shilpa > > Thanks to Paul Cuzner for providing inputs about pre and post hooks > available in backup utilities like NetBackup. > > * > **Initial draft:* > ============== > > Case 1 - Registered Consumer > ---------------------------- > > Consumer application has to register by giving a session name. > > glusterbackupapi register <sessionname> <host> <volume> > > > > When the following command run for the first time, it will do full scan. > next onwards it does incremental. Start time for incremental is last > backup time, endtime will be current time. > > glusterbackupapi <sessionname> --out-file=out.txt > > --out-file is optional argument, default output file name is > `output.txt`. Output file will have file paths. > > > > Case 2 - Unregistered Consumer > ----------------------------- > > Start time and end time information will not be remembered, every time > consumer has to send start time and end time if incremental. > > For Full backup, > > glusterbackupapi full <host> <volume> --out-file=out.txt > > For Incremental backup, > > glusterbackupapi inc <host> <volume> <STARTTIME> <ENDTIME> > --out-file=out.txt > > where STARTTIME and ENDTIME are in unix timestamp format. > > > *Technical overview* > ================== > 1. Using host and volume name arguments, it fetches volume info and > volume status to get the list of up bricks/nodes. > 2. Executes brick/node agent to get required details from brick. (TBD: > communication via RPC/SSH/gluster system:: execute) > 3. If full scan, brick/node agent will gets list of files from that > brick backend and generates output file. > 4. If incremental, it calls Changelog History API, gets distinct GFID's > list and then converts each GFID to path. > 5. Generated output files from each brick node will be copied to > initiator node. > 6. Merges all the output files from bricks and removes duplicates. > 7. In case of session based access, session information will be saved by > each brick/node agent. > > > *Issues/Challenges* > ================= > 1. If timestamp different in gluster nodes. We are assuming, in a > cluster TS will remain same. > 2. If a brick is down, how to handle? We are assuming, all the bricks > should be up to initiate backup(atleast one from each replica) > 3. If changelog not available, or broken in between start time and end > time, then how to get the incremental files list. As a prerequisite, > changelog should be enabled before backup. > 4. GFID to path conversion, using `find -samefile` or using > `glusterfs.pathinfo` xattr on aux-gfid-mount. > 5. Deleted files, if we get GFID of a deleted file from changelog how to > find path. Do backup api requires deleted files list? > 6. Storing session info in each brick nodes. > 7. Communication channel between nodes, RPC/SSH/gluster system:: > execute... etc? > > > Kotresh, Ajeet, Please add if I missed any points. > > > -- > regards > Aravinda > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
