[saghm]

> If you have a backup of your repository, you can create patches for the commits made after it, restore from backup, and replay those you want to keep.

Maybe I'm just too young to have a good perspective on this (due to only becoming a developer after git was fairly well established), but I thought that version control itself is supposed to be your backup

[Someone]

A backup by necessity is a copy; with centralized version control as svn is, you don't have a copy of the repository, so you have to make one some way.

(Decentralized version control is only slightly different; if you lose the 'main' repository and don't have an exact clone (aka a backup), you may be able to glue together something from other repositories that is close to or equal to what you had, but there is no way to know for sure)

[y4mi]

it is for as long as your repository is undamaged.

its rare, but sometimes a repository can get damaged beyond repair. keeping it inside of a cloud storage directory like google drive, dropbox or similar makes it prone for fatal errors.

in such a scenario a backup of the full repository is required. in gits case, remote sources can fill the 'backup' role pretty easily, as everything gets pushed to a remote server. this is obviously not enough safety if you're a bigger enterprise, they'll need additional safety guards/backups, but its sufficient for most people.