How To: Backup a SourceSafe Database

Need some time to catch up on your email or pay some bills?  Wanna read an online article about your favorite baseball, cricket, or football team's latest game?  Here's a five second task whose completion can convince the toughest micro-manager that you've been burning the candle at both ends to protect your company's vital data.

Create a SourceSafe database disaster recovery plan. And since everything with an acronym connotes hard work, give it a fat one like SSDDRP. Your boss will love it.

To Backup a Visual SourceSafe Database

Copy it to a new location…

1.      Create a share on a computer that does not contain your SourceSafe database (eg, \\server2\vss_backup$).

Impress your boss   Insert a $ symbol after the name of your share to hide it from casual browsers on the network.

2.      In Windows Explorer on the SourceSafe server, select the SourceSafe installation folder (eg, c:/Program Files/Microsoft Visual Studio/VSS).

3.      On the Edit menu, click Copy.

4.      Browse to the backup share you created in step 1.

5.      On the Edit menu, click Paste.

 

Optionally, you can create a tape backup of the server on which your backed up database is stored.  It's that easy. 

+++++++++++++++++++
הודעה זו מסופקת "כפי שהיא" ללא כל אחריות או חיובים, ואינה נותנת לך זכויות כלשה.

Published 07 October 03 11:41 by KorbyP

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# AsbjornM said on October 7, 2003 5:59 PM:
Practical joke? :) What's wrong with SSARC? Or what about this document: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvss/html/vssbest.asp New Databases Avoid creating a new database by copying an existing one. Doing so can potentially cause problems because the globally unique identifier (GUID) in the Um.dat will be the same for both databases. Does not apply anymore? (since if this is an reasonable way of making backups, it would also be an reasonable way of duplicating the base to get same users etc..)
# Korby Parnell said on October 8, 2003 2:31 AM:
Asbjorn, good questions and sound comments, as usual. I should have mentioned SSArc :-(. However, um.dat and database GUID conflicts (which I allude to as a "database identifier" in http://blogs.gotdotnet.com/korbyp/PermaLink.aspx/6ccac6cd-584a-49e1-b4d8-e8e25f8f6166) have no bearing on my suggested backup method. And, for the record, this post was not a practical joke. Well, not entirely... I am practically incapable of humor; Microsoft hires humorous programmer/writers cheap and then hires expensive editors to train the humor out of us. ;-) Admittedly, my guidance is a bit rough around the edges :-). More importantly, it completely ignores the existence of a great backup feature in VSS. So much trying to pick the low hanging fruit on a busy day. My feature team is going to pelt me that fruit tomorrow, no doubt. Hah! I was so excited to explain how easy it is to backup a VSS database that I forgot to mention SSArc as the right and proper tool for the job. Technical reviews are helpful!!! Allow me to address the roughness of my guidance first. Then, I will talk about the feature I failed to mention, Archive and Restore. Finally, I will explain why um.dat and database guids have no bearing on this task. Feel free to highlight any inaccuracies in my explanation. Also, raise your hand if you don’t understand something or want more details. I aim to please. To backup a SourceSafe database (easy method but copy is uncompressed): Copy the /data folder from the SourceSafe database directory to a share on a different server. You don't actually have to backup the entire /VSS folder as stated in this post to be able to recover from database corruption. Honestly, backing up a VSS database is that easy. In fact, I've seen many SourceSafe Analyze scripts that backup the /data directory using this method, just in case something goes haywire. If you require redundancy and failover, copy the entire database directory. If you are serious about security, you can unshare the backup folder after copying the database. Concerned about viruses? Disconnect the server from the network. Downright paranoid? Unplug the backup server and/or put it in a safe place. As far as I know (the MSFT IT folks don't bother to tell me the details), my backup server lives in a halon fire retardant, temperature-controlled, RAID arrayed, earthquake free, waterproof, thermonuclear blast-protected, fully clustered lab in Scandinavia that gets backed up every 10 minutes to a similar lab in Colorado. Copy ../vss/data --> Paste \\srv2\vssdb_backup is the quick and dirty way to backup a database. If your database ever gets corrupted, you can simply replace its /data directory with the backed up copy. So what is SSARC? For those of you who are just learning the ins and outs of VSS, SSARC.exe is SourceSafe's archive utility, otherwise known as "Archive Projects..." SSArc is available from the command line as SSArc and in the SourceSafe Admin GUI from--believe it or not--the Archive menu. It provides a flexible mechanism for backing up and *compressing* an entire VSS database *or specific projects* therein. Please note that compression ratios vary depending on whether the files in your database are binary, or not. As Asbjorn points out, SSArc _is_ the sensible alternative for backing up a SourceSafe database on a regular basis. Its advantages include: 1) Data Compression -- its backup copy consumes less space on disk than copy-->paste /data folder method) 2) Granularity -- enables you to backup a database on a project-by-project basis. 3) Reduces Database Size -- you can remove backed up project data from the database. 4) SSArc.exe in combination with SSRestor.exe, allows you to MOVE PROJECTS between databases. Asbjorn, you quote a section in the VSS Best Practices Whitepaper (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvss/html/vssbest.asp) that does not apply to backing up a VSS database. Instead, it pertains to _creating a new_ VSS database by cloning an existing one and then deleting its projects. Why would somebody attempt to do this? Usually, because they hope to retain their laboriously constructed user list and user rights assignments, a task which is otherwise impossible using VSS Admin out of the box. (If you do need to do this, I have a utility that can do the job. Email me for particulars.) I discuss the um.dat limitation in my post 'Cloning VSS Settings across Databases' (http://blogs.gotdotnet.com/korbyp/PermaLink.aspx/6ccac6cd-584a-49e1-b4d8-e8e25f8f6166). For more information about archive and restore, see http://support.microsoft.com/default.aspx?scid=kb;en-us;176875. Interestingly, a user on one of the public newsgroups brought up the VSS database GUID limitation issue yesterday: http://communities.microsoft.com/newsgroups/previewFrame.asp?ICP=msdn&sLCID=us&sgroupURL=microsoft.public.vstudio.sourcesafe&sMessageID=%253COox9DLEjDHA.548@TK2MSFTNGP11.phx.gbl%253E Standard MSFT Disclaimer: Microsoft kann für die Richtigkeit und Vollständigkeit der Inhalte in dieser Newsgroup keine Haftung übernehmen.
# Hagen Brown said on October 16, 2003 5:05 PM:
You menton there are GUID conflicts with um.dat if a new database is created by copying existing one. Specifically what kinds of problems occur if two complete copies of vss exist in 2 different directories on the same server?

Leave a Comment

(required) 
(optional)
(required) 

Search

Go

This Blog

Syndication

Page view tracker