6

Suppose I use Git, Subversion or any other version control system for managing my writing. So my texts are preserved together with change history and if I accidentally delete something I can use history to restore it.

Does this mean I no longer need to backup my work?

Improve this question
  • Are you backing up your source-control repository? – Monica Cellio May 1 '15 at 22:04
  • Not really sure this old question is on-topic, since it's not about writing, more about backup software. It's about a writing tool, but the question and the answers could apply to backing up source code or 3-D models or music. If we go by the consensus in this meta thread, we should close this or at least edit it to be more on-topic. I'll place this on hold for now, but if people want to argue for keeping it open, let's talk about editing it to make it more relevant to the topic of this site. – Goodbye Stack Exchange May 2 '15 at 16:05
  • @NeilFein That's seriously annoying. You're not sure it's on topic, yet you choose to put it on hold because who knows... this question might suddenly bite you. – sharptooth May 5 '15 at 8:07
11

You still need backups. Version control and backups are orthogonal concepts and should be used together, one is not a replacement for another.

Yes, version control will persist the change history in the repository, but the repository itself is not protected just as any computer file is not protected. If the drive where the repository is stored dies the repository contents gets inaccessible. If the filetree comprising the repository is corrupted due to a software bug, malicious software, or user error the data stored there is corrupted or lost. If you use a third-party service for hosting your repository that service may undergo some problems that will lead to your repository data being lost.

To prevent data loss in such scenarios you need backup of your repository. Don't confuse the two concepts.

Improve this answer
  • 3
    +1 As sharptooth correctly notes, if you have your version control on the same drive as your backups, you're living in a fool's paradise. – Robusto Feb 18 '13 at 14:12
4

Yes, you still need backups.

However, the form that backup can take can vary.

  1. Version Control might include it

    If you are using git, then every time you "push" to an off-site repository, you have created a backup of your project in its entirety - including a catalog of your changes. This may be sufficient for your needs. In this case, you have two copies of your text: locally, every version, and in the off-site repository (such as BitBucket or github), every version.

    If you're using Subversion, then only the central repository includes a catalog of your changes. If you are only interested in backing up the most recent version of your text, then every time you commit to Subversion, you are creating a backup. In this case, you have two copies of your text: locally, the current version, and in the Subversion repository, every version.

  2. Automatic Online Backups

    You have a few choices in this area, but the only one that I can recommend is Dropbox. With Dropbox, your files are stored locally, backed up to a central location, and synchronized with your other computers where you have Dropbox installed. This is good, because it means that if your computer is stolen or your hardware breaks, you can seamlessly pick up from your last place on an existing (or new) machine.

    The disadvantage of using Dropbox is that there is potential for for someone to gain access to your account, delete all of your files, and for all of the copies of your work to be deleted upon the next synchronization. If you're worried about that possibility, I advise using at least one other backup method for important documents that are tracked by Dropbox.

  3. Manual Online Backups

    There are a number of options in this area. The advantage that they have over option 2 is that you are not regularly synchronizing from the server to your machine. However, they hold the disadvantage of being manual processes. These are similar to option 1, but if you use Subversion then you may wish to manually back up the central repository on a regular basis.

  4. Local Backups

    This boils down to backing up onto local media - most likely optical media (CDs, DVDs) or a different hard drive (most likely an external hard drive or flash drive). These have the advantage of not requiring a network connection to backup or restore. There are two problems with this method:

    1. The backup is local. In the event of a fire or other disaster, your work will be lost.
    2. The backup media can fail. This is particularly of concern with external hard drives and flash drives, as most likely all of your backups will be stored on one device. In the event that your external drive and your local hard drive both lose data at the same time, you're completely out of luck (unless you have a remote backup).

Personally, I recommend using the following solution:

  • Store your files in a Dropbox synched folder.
  • Version control your files with git.
  • Push your local repository after each work session (or more often) to a BitBucket hosted repository.
  • Monthly or more often, back up your files locally, preferably on an external hard drive or flash drive.
Improve this answer
  • Monthly? It's not a whole lot of data we're talking about, here. Perhaps a few gigabytes, at most, if you include research material, images and so on? That kind of amount is certainly practical to backup much more often (weekly or even daily), especially if you are doing differential or incremental backups, copying only what has changed. Consider what happens if something fails just before you are about to make a backup. How much work do you lose? That said, +1 for the outline of options. – user Feb 22 '13 at 10:00
  • The only situation where the monthly backup (from my recommended case) comes into play is if there is simultaneously an issue with both Dropbox and Bitbucket (or more likely, your own Internet connection) AND a hardware failure or theft. Since Dropbox is backed up continuously while you're connected to the Internet, the odds are very high that you'll not lose more than maybe the last save worth of work. And since you're pushing to Bitbucket after each session, even if Dropbox fails or is compromised, you can pull anything you need down from Bitbucket. – corvec Feb 23 '13 at 17:20
1

While another answer is correct in saying that version control and backing up are orthogonal concepts, your local repository can have a remote repository synched with it to effectively provide a backup of your local history in the cloud. If you don't already have a remote repository, you can set one up on http://github.com or http://bitbucket.org. In this regard it can also be a tool to help you back up in addition to providing version control.

Improve this answer
  • This means you heavily depend on a third-party service. What if there's a data loss in GitHub? – sharptooth Feb 18 '13 at 14:20
  • Then I still have it in entirety locally (and on time machine). The same is true of every backup. You can have as many remotes as you want in git, however, if you are paranoid. Some people remote to their own dropbox as a secondary location. – Peter DeWeese Feb 18 '13 at 14:23
  • Agree with Peter. What guarantee do you have that your backup device won't fail? At some point, you have to trust something. You can have backups of backups, store your work on three different online services, but then, when will you have time to write? – Shantnu Tiwari Feb 19 '13 at 9:46
1

A version control repository IS a backup. But you really should back up the respository.

As always, back ups should be to a different device than the main file: a hard drive on another computer, CD, thumb drive, whatever. A backup on the same disk drive is worth something, but the most likely reason to need a backup is because the hard drive failed.

For real safety, keep the backup in a separate location from the original. Like I used to work for a small company, and I took backups home with me, so if the building burned down, we still had our backups. For my home stuff, I sometimes take a backup to work and stuff it in a drawer in my desk. 'Can't imagine the company minds me using up a few square inches of desk space.

Personally, I'm bad in that I only make my backups once every few months. Backup schedule should depend on how frequently your data changes and how important it is.

Improve this answer
1

If you're backing up your git repo by simply using remote repositories, then no, you don't need further backups.

When you make a commit, you're making a backup copy and putting it in the .git folder. If you push your git repo up to github or anywhere else, you are essentially making a backup copy of your repo.

That being said, I do backup all of my remote repositories (just like github.com probably does behind the scenes) so that if my git server goes down, restoring it takes only a moment and I don't have to go searching for repository clones everywhere.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.