{"thread":{"id":"13488","subject":"how to backup git","startedAt":"2008-05-12T06:08:54Z","lastAt":"2008-05-12T23:43:36Z","messageCount":21,"participants":["bill lam","Sverre Hvammen Johansen","Tobias Sarnowski","Eric Hanchrow","Johannes Schindelin","Miklos Vajna","Heikki Orsila","Jakub Narebski","Tim Harper","Sverre Rabbelier","Daniel Barkalow","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"76677","messageId":"4827DEF6.1050005@gmail.com","threadId":"13488","inReplyTo":null,"subject":"how to backup git","fromName":"bill lam","fromEmail":"cbill.lam@gmail.com","sentAt":"2008-05-12T06:08:54Z","receivedAt":"2008-05-12T06:08:54Z","isPatch":false,"sender":{"key":"cbill.lam@gmail.com","avatar":null},"body":"Hello, this should be a simple question. How to backup a git repository but \nexcluding files that not under versioned? If I cp or tar or rsync the \ndirectory. All non-versioned files are added.\n\nregards,\n"},{"id":"76680","messageId":"EC8B6A6F-31FA-498C-92A1-DE2F0645C56F@new-thoughts.org","threadId":"13488","inReplyTo":"4827DEF6.1050005@gmail.com","subject":"Re: how to backup git","fromName":"Tobias Sarnowski","fromEmail":"sarnowski@new-thoughts.org","sentAt":"2008-05-12T06:36:54Z","receivedAt":"2008-05-12T06:36:54Z","isPatch":false,"sender":{"key":"sarnowski@new-thoughts.org","avatar":null},"body":"Hi bill,\n\nBacking up the \".git\" directory is all you need. You can also clone it \nas a bare repository (see git clone --bare).\n\nAfterwards \"git checkout\" is your friend.\n\nTobias\n\nAm 12.05.2008 um 08:08 schrieb bill lam :\n\n> Hello, this should be a simple question. How to backup a git \n> repository but excluding files that not under versioned? If I cp or \n> tar or rsync the directory. All non-versioned files are added.\n>\n> regards\n"},{"id":"76679","messageId":"loom.20080512T062707-662@post.gmane.org","threadId":"13488","inReplyTo":"4827DEF6.1050005@gmail.com","subject":"Re: how to backup git","fromName":"Sverre Hvammen Johansen","fromEmail":"hvammen@gmail.com","sentAt":"2008-05-12T06:40:53Z","receivedAt":"2008-05-12T06:40:53Z","isPatch":false,"sender":{"key":"hvammen@gmail.com","avatar":"https://gravatar.com/avatar/d1fc25ec327eea135af60fe7b56b2a2e21f711aa32167e7f505014ec88aa24bc?d=mp&s=160"},"body":"bill lam gmail.com> writes:\n\n> Hello, this should be a simple question. How to backup a git repository but \n> excluding files that not under versioned? If I cp or tar or rsync the \n> directory. All non-versioned files are added.\n\nA repository can be backed up by backing up the .git directory.\n\nIf you want to back up the HEAD commit, use git-archive as follows:\n\n $ git archive --prefix=my-backup/ HEAD | gzip >my-backup.tar.gz\n\nIf you want to back up the working directory, commit it to a temporary branch\nbefore you use 'git archive'.\n\n-- \nSverre Hvammen Johansen\n"},{"id":"76704","messageId":"87ej87is50.fsf@offby1.atm01.sea.blarg.net","threadId":"13488","inReplyTo":"4827DEF6.1050005@gmail.com","subject":"Re: how to backup git","fromName":"Eric Hanchrow","fromEmail":"offby1@blarg.net","sentAt":"2008-05-12T13:11:39Z","receivedAt":"2008-05-12T13:11:39Z","isPatch":false,"sender":{"key":"eric.hanchrow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3145?v=4"},"body":">>>>> \"bill\" == bill lam writes:\n\n bill> Hello, this should be a simple question. How to backup a git\n bill> repository but excluding files that not under versioned? If I\n bill> cp or tar or rsync the directory. All non-versioned files are\n bill> added.\n\nI'd rsync just the .git directory.\n\n-- \nIt sounds churlish to bash a film that's as bereft of bad\nthoughts as a tiny puppy. But when the puppy licks your face for 108\nminutes, enough's enough.\n -- Matt Zoller Seitz, NY Times\n"},{"id":"76707","messageId":"alpine.DEB.1.00.0805121428310.30431@racer","threadId":"13488","inReplyTo":"87ej87is50.fsf@offby1.atm01.sea.blarg.net","subject":"Re: how to backup git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-12T13:28:58Z","receivedAt":"2008-05-12T13:28:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 May 2008, Eric Hanchrow wrote:\n\n> >>>>> \"bill\" == bill lam writes:\n> \n> bill> Hello, this should be a simple question. How to backup a git\n> bill> repository but excluding files that not under versioned? If I\n> bill> cp or tar or rsync the directory. All non-versioned files are\n> bill> added.\n> \n> I'd rsync just the .git directory.\n\nNote that this is necessary if you want to keep the reflogs (clone would \nnot copy them).\n\nCiao,\nDscho\n"},{"id":"76708","messageId":"48285087.3090402@gmail.com","threadId":"13488","inReplyTo":"alpine.DEB.1.00.0805121428310.30431@racer","subject":"Re: how to backup git","fromName":"bill lam","fromEmail":"cbill.lam@gmail.com","sentAt":"2008-05-12T14:13:27Z","receivedAt":"2008-05-12T14:13:27Z","isPatch":false,"sender":{"key":"cbill.lam@gmail.com","avatar":null},"body":"Johannes Schindelin wrote:\n >> I'd rsync just the .git directory.\n\nThanks to all responders for quick reply. I still have a related question. svn \nhas a hotcopy command to ensure integrity so that it is possible to backup \nwithout shutting down the svn server. If someone update the .git while I am \nperforming backup using tar or rsync? Will the atomicity of that commit still \npreserve in my backup copy?\n\nregards,\n"},{"id":"76711","messageId":"20080512145426.GN27724@genesis.frugalware.org","threadId":"13488","inReplyTo":"48285087.3090402@gmail.com","subject":"Re: how to backup git","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-05-12T14:54:27Z","receivedAt":"2008-05-12T14:54:27Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Mon, May 12, 2008 at 10:13:27PM +0800, bill lam wrote:\n> Thanks to all responders for quick reply. I still have a related question. \n> svn has a hotcopy command to ensure integrity so that it is possible to \n> backup without shutting down the svn server. If someone update the .git \n> while I am performing backup using tar or rsync? Will the atomicity of that \n> commit still preserve in my backup copy?\n\nthe only problem can be when someone runs git-gc (as it runs git-prune)\nwhile you are doing the backup. other commands never remove objects.\n"},{"id":"76714","messageId":"alpine.DEB.1.00.0805121606010.30431@racer","threadId":"13488","inReplyTo":"48285087.3090402@gmail.com","subject":"Re: how to backup git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-12T15:08:21Z","receivedAt":"2008-05-12T15:08:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[please do not cull the Cc: list]\n\nOn Mon, 12 May 2008, bill lam wrote:\n\n> Johannes Schindelin wrote:\n> > > I'd rsync just the .git directory.\n> \n> Thanks to all responders for quick reply. I still have a related \n> question. svn has a hotcopy command to ensure integrity so that it is \n> possible to backup without shutting down the svn server. If someone \n> update the .git while I am performing backup using tar or rsync? Will \n> the atomicity of that commit still preserve in my backup copy?\n\nNo, rsync is particularly dumb in that respect. The safest thing would be \nto back up the reflogs first (e.g. with rsync), then repack and then clone \n(the clone will transmit the objects referenced by the reflogs, too). \nNote: the same holds _not_ true for a simple fetch.\n\nBut then, you usually do not want to back up reflogs anyway, since they \nare purely local and not visible to anybody else.\n\nCiao,\nDscho\n"},{"id":"76717","messageId":"20080512152731.GM31039@zakalwe.fi","threadId":"13488","inReplyTo":"alpine.DEB.1.00.0805121606010.30431@racer","subject":"Re: how to backup git","fromName":"Heikki Orsila","fromEmail":"shdl@zakalwe.fi","sentAt":"2008-05-12T15:27:31Z","receivedAt":"2008-05-12T15:27:31Z","isPatch":false,"sender":{"key":"shdl@zakalwe.fi","avatar":null},"body":"On Mon, May 12, 2008 at 04:08:21PM +0100, Johannes Schindelin wrote:\n> No, rsync is particularly dumb in that respect. The safest thing would be \n> to back up the reflogs first (e.g. with rsync), then repack and then clone \n> (the clone will transmit the objects referenced by the reflogs, too). \n> Note: the same holds _not_ true for a simple fetch.\n> \n> But then, you usually do not want to back up reflogs anyway, since they \n> are purely local and not visible to anybody else.\n\nIs there a simple and efficient mechanism for incremental backups?\nIt should be safe with respect to simultaneous repository access.\nIncrementals should be efficient weven when a user runs \"git gc\". \nPreferably I would like to have one file per day: \nmyrepo.YYYY-MM-DD.increment (and occasionally myrepo.YYYY-MM-DD.full)\nI believe this is a common administration problem; \nsomething like \"git-backup\" script/tool would be nice so that not all \nthe admins need consider these issues.\n\nCurrently, I'm doing daily clones of repos, and I preserve those cloned \ndirectories.\n\n-- \nHeikki Orsila\nheikki.orsila@iki.fi\nhttp://www.iki.fi/shd\n"},{"id":"76724","messageId":"alpine.DEB.1.00.0805121804500.30431@racer","threadId":"13488","inReplyTo":"20080512152731.GM31039@zakalwe.fi","subject":"Re: how to backup git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-12T17:07:28Z","receivedAt":"2008-05-12T17:07:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 May 2008, Heikki Orsila wrote:\n\n> On Mon, May 12, 2008 at 04:08:21PM +0100, Johannes Schindelin wrote:\n> > No, rsync is particularly dumb in that respect. The safest thing \n> > would be to back up the reflogs first (e.g. with rsync), then repack \n> > and then clone (the clone will transmit the objects referenced by the \n> > reflogs, too). Note: the same holds _not_ true for a simple fetch.\n> > \n> > But then, you usually do not want to back up reflogs anyway, since \n> > they are purely local and not visible to anybody else.\n> \n> Is there a simple and efficient mechanism for incremental backups?\n\nUmm. \"git fetch\"?\n\nLike I said, it does not get the reflogs, but if you want to back up a \nrepository, the safest is to clone once, and fetch later. Or you could \nset up a remote with the --mirror option, if you want to preserve the \nrefs' namespaces.\n\nCiao,\nDscho\n"},{"id":"76736","messageId":"20080512180720.GN31039@zakalwe.fi","threadId":"13488","inReplyTo":"alpine.DEB.1.00.0805121804500.30431@racer","subject":"Re: how to backup git","fromName":"Heikki Orsila","fromEmail":"shdl@zakalwe.fi","sentAt":"2008-05-12T18:07:20Z","receivedAt":"2008-05-12T18:07:20Z","isPatch":false,"sender":{"key":"shdl@zakalwe.fi","avatar":null},"body":"On Mon, May 12, 2008 at 06:07:28PM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 12 May 2008, Heikki Orsila wrote:\n> \n> > On Mon, May 12, 2008 at 04:08:21PM +0100, Johannes Schindelin wrote:\n> > > No, rsync is particularly dumb in that respect. The safest thing \n> > > would be to back up the reflogs first (e.g. with rsync), then repack \n> > > and then clone (the clone will transmit the objects referenced by the \n> > > reflogs, too). Note: the same holds _not_ true for a simple fetch.\n> > > \n> > > But then, you usually do not want to back up reflogs anyway, since \n> > > they are purely local and not visible to anybody else.\n> > \n> > Is there a simple and efficient mechanism for incremental backups?\n> \n> Umm. \"git fetch\"?\n> \n> Like I said, it does not get the reflogs, but if you want to back up a \n> repository, the safest is to clone once, and fetch later. Or you could \n> set up a remote with the --mirror option, if you want to preserve the \n> refs' namespaces.\n\nPreferably some solution that does not require too much understanding of \nGit internals so that admins will actually use it, instead of hacking \ntheir own inefficient backup scripts.\n\nCould someone please write a \"git-backup\" script?-)\n\n-- \nHeikki Orsila\nheikki.orsila@iki.fi\nhttp://www.iki.fi/shd\n"},{"id":"76738","messageId":"alpine.DEB.1.00.0805121920120.30431@racer","threadId":"13488","inReplyTo":"20080512180720.GN31039@zakalwe.fi","subject":"Re: how to backup git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-12T18:21:02Z","receivedAt":"2008-05-12T18:21:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 May 2008, Heikki Orsila wrote:\n\n> On Mon, May 12, 2008 at 06:07:28PM +0100, Johannes Schindelin wrote:\n> \n> > On Mon, 12 May 2008, Heikki Orsila wrote:\n> > \n> > > On Mon, May 12, 2008 at 04:08:21PM +0100, Johannes Schindelin wrote:\n> > > > No, rsync is particularly dumb in that respect. The safest thing \n> > > > would be to back up the reflogs first (e.g. with rsync), then \n> > > > repack and then clone (the clone will transmit the objects \n> > > > referenced by the reflogs, too). Note: the same holds _not_ true \n> > > > for a simple fetch.\n> > > > \n> > > > But then, you usually do not want to back up reflogs anyway, since \n> > > > they are purely local and not visible to anybody else.\n> > > \n> > > Is there a simple and efficient mechanism for incremental backups?\n> > \n> > Umm. \"git fetch\"?\n> > \n> > Like I said, it does not get the reflogs, but if you want to back up a \n> > repository, the safest is to clone once, and fetch later. Or you \n> > could set up a remote with the --mirror option, if you want to \n> > preserve the refs' namespaces.\n> \n> Preferably some solution that does not require too much understanding of \n> Git internals so that admins will actually use it, instead of hacking \n> their own inefficient backup scripts.\n> \n> Could someone please write a \"git-backup\" script?-)\n\nHeikki, why don't you just go with the \"git fetch\" approach I described? \nWe do not need \"git backup\" when \"git fetch\" does already what you want.\n\nCiao,\nDscho\n"},{"id":"76739","messageId":"20080512183615.GO31039@zakalwe.fi","threadId":"13488","inReplyTo":"alpine.DEB.1.00.0805121920120.30431@racer","subject":"Re: how to backup git","fromName":"Heikki Orsila","fromEmail":"shdl@zakalwe.fi","sentAt":"2008-05-12T18:36:15Z","receivedAt":"2008-05-12T18:36:15Z","isPatch":false,"sender":{"key":"shdl@zakalwe.fi","avatar":null},"body":"On Mon, May 12, 2008 at 07:21:02PM +0100, Johannes Schindelin wrote:\n> Heikki, why don't you just go with the \"git fetch\" approach I described? \n> We do not need \"git backup\" when \"git fetch\" does already what you want.\n\nI need efficient (small) daily increment files. What I could do is \nsomething like:\n\n1. rm -rf yesterday ; mv today yesterday\n\n2. git clone yesterday today\n\n3. cd today && git fetch /path/to/repo\n\n4. create an increment file (from yesterday to today) or a full\n\nThe above should just be something like (why not make this easy?):\n\n1. git backup /path/to/repo /backup/location/\n\nAnd restoration should be something like:\n\n1. git backup --restore /backup/location/foo /path/to/repo\n\nAm I missing something?\n\n-- \nHeikki Orsila\nheikki.orsila@iki.fi\nhttp://www.iki.fi/shd\n"},{"id":"76740","messageId":"20080512183803.GP31039@zakalwe.fi","threadId":"13488","inReplyTo":"20080512183615.GO31039@zakalwe.fi","subject":"Re: how to backup git","fromName":"Heikki Orsila","fromEmail":"shdl@zakalwe.fi","sentAt":"2008-05-12T18:38:03Z","receivedAt":"2008-05-12T18:38:03Z","isPatch":false,"sender":{"key":"shdl@zakalwe.fi","avatar":null},"body":"On Mon, May 12, 2008 at 09:36:15PM +0300, Heikki Orsila wrote:\n> 3. cd today && git fetch /path/to/repo\n\nThat was a mistake, a bare fetch is not enough.\n\n-- \nHeikki Orsila\nheikki.orsila@iki.fi\nhttp://www.iki.fi/shd\n"},{"id":"76747","messageId":"m38wyf4als.fsf@localhost.localdomain","threadId":"13488","inReplyTo":"alpine.DEB.1.00.0805121920120.30431@racer","subject":"Re: how to backup git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-12T18:54:15Z","receivedAt":"2008-05-12T18:54:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin writes:\n\n> On Mon, 12 May 2008, Heikki Orsila wrote:\n> \n>> On Mon, May 12, 2008 at 06:07:28PM +0100, Johannes Schindelin wrote:\n>> \n>>> On Mon, 12 May 2008, Heikki Orsila wrote:\n \n>>>> Is there a simple and efficient mechanism for incremental backups?\n>>> \n>>> Umm. \"git fetch\"?\n>>> \n>>> Like I said, it does not get the reflogs, but if you want to back up a \n>>> repository, the safest is to clone once, and fetch later. Or you \n>>> could set up a remote with the --mirror option, if you want to \n>>> preserve the refs' namespaces.\n>> \n>> Preferably some solution that does not require too much understanding of \n>> Git internals so that admins will actually use it, instead of hacking \n>> their own inefficient backup scripts.\n>> \n>> Could someone please write a \"git-backup\" script?-)\n> \n> Heikki, why don't you just go with the \"git fetch\" approach I described? \n> We do not need \"git backup\" when \"git fetch\" does already what you want.\n\nI think that bundles (see git-bundle) would be what you want (please\nread GitFaq/GitTips/\"Git in Nutshell\" for explanation and use cases).\n\n\"git fetch\" (perhaps using bundle) would save state of refs (heads,\nremote branches, tags) and object repository. To save state of\nworking area and index I think it would be best to use 'git-stash'\nbefore creating backup, and unstash after it; see documentation for\ngit-stash. What is left is: reflogs, configuration, hooks, grafts and\nshallow, repository local excludes file, repository local attributes\nfile[*1*].\n\n[*1*] Which is not mentioned in Documentation/repository-layout.txt\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"76751","messageId":"73584838-DF17-4CDB-92CA-363ED9DA9582@gmail.com","threadId":"13488","inReplyTo":"20080512183803.GP31039@zakalwe.fi","subject":"Re: how to backup git","fromName":"Tim Harper","fromEmail":"timcharper@gmail.com","sentAt":"2008-05-12T18:58:07Z","receivedAt":"2008-05-12T18:58:07Z","isPatch":false,"sender":{"key":"timcharper@gmail.com","avatar":"https://gravatar.com/avatar/1a2e0c06c7862ff065ee6b1d53195333a5a0577c040ecb2856a150d8e0b00ecd?d=mp&s=160"},"body":"\nOn May 12, 2008, at 12:38 PM, Heikki Orsila wrote:\n\n> On Mon, May 12, 2008 at 09:36:15PM +0300, Heikki Orsila wrote:\n>> 3. cd today && git fetch /path/to/repo\n>\n> That was a mistake, a bare fetch is not enough.\n\nYeah, Heikki - I wonder if you're missing the point. In our case, we \ndon't bother with repository backups here. Everyone developer has a \nfull copy of the repository, and any one of them could be used to \ncreate a new \"central\" git repository. If our central git repository \ngoes down - we've got 9 others floating around on different laptops \nand computers. You can't beat that kind of redundancy. You'd have to \nnuke Utah to take us out (btw: please don't nuke Utah).\n\nTim\n\n>\n>\n> -- \n> Heikki Orsila\n> heikki.orsila@iki.fi\n> http://www.iki.fi/shd\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"76754","messageId":"20080512191002.GQ31039@zakalwe.fi","threadId":"13488","inReplyTo":"73584838-DF17-4CDB-92CA-363ED9DA9582@gmail.com","subject":"Re: how to backup git","fromName":"Heikki Orsila","fromEmail":"shdl@zakalwe.fi","sentAt":"2008-05-12T19:10:02Z","receivedAt":"2008-05-12T19:10:02Z","isPatch":false,"sender":{"key":"shdl@zakalwe.fi","avatar":null},"body":"On Mon, May 12, 2008 at 12:58:07PM -0600, Tim Harper wrote:\n> In our case, we \n> don't bother with repository backups here. Everyone developer has a \n> full copy of the repository, and any one of them could be used to \n> create a new \"central\" git repository.\n\nSo you assume everyone syncs everyone else often enough. I don't think \nmany organizations want to rely on that assumption. The point is to \nhave a simple, efficient and manageable backup system that \ndoes _not_ require knowledge of Git internals.\n\n-- \nHeikki Orsila\nheikki.orsila@iki.fi\nhttp://www.iki.fi/shd\n"},{"id":"76758","messageId":"bd6139dc0805121249q76282be1mfc888e3707598a29@mail.gmail.com","threadId":"13488","inReplyTo":"20080512191002.GQ31039@zakalwe.fi","subject":"Re: how to backup git","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-05-12T19:49:02Z","receivedAt":"2008-05-12T19:49:02Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Mon, May 12, 2008 at 9:10 PM, Heikki Orsila wrote:\n> So you assume everyone syncs everyone else often enough. I don't think\n> many organizations want to rely on that assumption. The point is to\n> have a simple, efficient and manageable backup system that\n> does _not_ require knowledge of Git internals.\n\nIsn't that what Dscho and others have mentioned a few times now?\nInitially you git clone the repo, every few hours you have cron do a\ngit pull and daily you do 'rm yesterday.tar.gz && mv today.tar.gz\nyesterday.tar.gz && tar czvf today.tar.gz .git '. Why would git need a\n'backup script' for something so trivial? I reckon everybody wants a\ndifferent type of backup too, so creating a 'git backup' would\nprobably not be very usefull to most.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"76797","messageId":"alpine.LNX.1.00.0805121647540.19665@iabervon.org","threadId":"13488","inReplyTo":"48285087.3090402@gmail.com","subject":"Re: how to backup git","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-05-12T21:19:32Z","receivedAt":"2008-05-12T21:19:32Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 12 May 2008, bill lam wrote:\n\n> Johannes Schindelin wrote:\n> > > I'd rsync just the .git directory.\n> \n> Thanks to all responders for quick reply. I still have a related question. svn\n> has a hotcopy command to ensure integrity so that it is possible to backup\n> without shutting down the svn server. If someone update the .git while I am\n> performing backup using tar or rsync? Will the atomicity of that commit still\n> preserve in my backup copy?\n\nThere's the risk that the backup will start, it will copy all of the \nobjects, then a git commit happens, which adds more objects (after rsync \nhas passed) and updates a \"refs\" entry to refer to one of them, and then \nrsync copies the \"refs\" directory.\n\nIt's likewise possible to have part of the information for a commit copied \nand part of it not. This commit will be clearly broken, however (one or \nmore objects not found). \n\nSo, essentially, every commit goes through the stages of not at all \nwritten, partially written but invalid, and valid and correct. \nIndependantly, which commit is the latest is updated atomically. It's \npossible for an ill-timed backup to get a branch updated to a commit \nthat's not yet valid in the backup. In you restored from this, you'd need \nto use one of several methods (mainly reflogs) to get back to the last \nvalid commit that got backed up.\n\nOn the other hand, git will never, even in this sort of backup, end up \nwith a commit that's valid but not completely correct.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"76803","messageId":"7vej87xioc.fsf@gitster.siamese.dyndns.org","threadId":"13488","inReplyTo":"alpine.LNX.1.00.0805121647540.19665@iabervon.org","subject":"Re: how to backup git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-12T22:26:59Z","receivedAt":"2008-05-12T22:26:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> On Mon, 12 May 2008, bill lam wrote:\n>\n>> Johannes Schindelin wrote:\n>> > > I'd rsync just the .git directory.\n>> \n>> Thanks to all responders for quick reply. I still have a related question. svn\n>> has a hotcopy command to ensure integrity so that it is possible to backup\n>> without shutting down the svn server. If someone update the .git while I am\n>> performing backup using tar or rsync? Will the atomicity of that commit still\n>> preserve in my backup copy?\n>\n> There's the risk that the backup will start, it will copy all of the \n> objects, then a git commit happens, which adds more objects (after rsync \n> has passed) and updates a \"refs\" entry to refer to one of them, and then \n> rsync copies the \"refs\" directory.\n>\n> It's likewise possible to have part of the information for a commit copied \n> and part of it not. This commit will be clearly broken, however (one or \n> more objects not found). \n>\n> So, essentially, every commit goes through the stages of not at all \n> written, partially written but invalid, and valid and correct. \n> Independantly, which commit is the latest is updated atomically. It's \n> possible for an ill-timed backup to get a branch updated to a commit \n> that's not yet valid in the backup. In you restored from this, you'd need \n> to use one of several methods (mainly reflogs) to get back to the last \n> valid commit that got backed up.\n>\n> On the other hand, git will never, even in this sort of backup, end up \n> with a commit that's valid but not completely correct.\n\nI think suggestions from old timers on this thread to first \"git fetch\" is\nto handle that concern. It may not get the commit that is being created\nsimultaneously when such a fetch to backup repository is running (but that\nwill be backed up during the next round), but at least the contents of the\nbackup repository would be self contained and correct. So a nightly fetch\n(perhaps with --mirror) into a backup repository, and then after the fetch\nfinishes, copying the backup repository to tape, would give you one copy a\nnight. Copying out from the central repository to backup repository would\nbe incremental, and until you repack the backup repository, the tape\nbackup of that backup repository could also be made incremental, as fetch\nwill be append-only into its objects/ part with updates to refs/ part.\n"},{"id":"76809","messageId":"alpine.LNX.1.00.0805121909440.19665@iabervon.org","threadId":"13488","inReplyTo":"7vej87xioc.fsf@gitster.siamese.dyndns.org","subject":"Re: how to backup git","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-05-12T23:43:36Z","receivedAt":"2008-05-12T23:43:36Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 12 May 2008, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> I think suggestions from old timers on this thread to first \"git fetch\" is\n> to handle that concern.\n\nYeah, \"git fetch\" is the right solution (although it's a pain to do a \nbackup of \"every repo under \" or \"every repo anywhere under \" \nthat way, which I suspect of being the real issue). I just wanted to get a \nnote into this thread of what problems using rsync can and cannot have, \nsince it's different (both more and less reliable) from what the original \nposter asked about.\n\n> It may not get the commit that is being created simultaneously when such \n> a fetch to backup repository is running (but that will be backed up \n> during the next round), but at least the contents of the backup \n> repository would be self contained and correct.\n\nAnd simultaneous commit isn't really an issue; nothing will back up work \nyou do right after the backup runs, and users can't tell whether they did \nthe commit before or after the backup if it's close.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}