: Does using version control system make backups unnecessary? Suppose I use Git, Subversion or any other version control system for managing my writing. So my texts are preserved together with change

Vote Up Vote Down

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.

(0)

Vote Up Vote Down

Yes, you still need backups.

However, the form that backup can take can vary.

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.
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.
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.
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:

The backup is local. In the event of a fire or other disaster, your work will be lost.
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.

(0)

Vote Up Vote Down

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.

(0)

Vote Up Vote Down

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 github.com or bitbucket.org. In this regard it can also be a tool to help you back up in addition to providing version control.

(0)

Vote Up Vote Down

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.

(0)