Game Development Community

Simple backup script

by Johnathon · 11/11/2007 (2:26 pm) · 20 comments

I wrote a simple little windows batch file that would backup my project to my server, however you can use it to copy it to your local hard-drive as well.

net use b: \domainName\UserName [i]passwordHere[/i] /PERSISTENT:no
del /s *.dso

IF EXIST B:\Backups\Torque\MyGame\%date:~0,3% RD B:\Backups\Torque\MyGame\%date:~0,3% /S /Q

xcopy C:\Torque\MyGame\* "B:\Backups\Torque\MyGame\%date:~0,3%\*" /y /s

net use b: /DELETE

and if you want it to backup on your local hardrive

del /s *.dso

IF EXIST C:\Backups\Torque\MyGame\%date:~0,3% RD C:\Backups\Torque\MyGame\%date:~0,3% /S /Q

xcopy C:\Torque\MyGame\* "C:\Backups\Torque\MyGame\%date:~0,3%\*" /y /s

I then use my Windows Scheduler to schedule a backup everynight.

net use b: \domainname\username [i]passwordhere[/i] /PERSISTANT:no
This is where you connect to your server that you want to backup your data to. If you are backing up to your local hard drive you won't need to use this command. /PERSISTANT means that the network connection will not re-connect when you reboot your computer. It connects this one time only.

del /s *.dso
This deletes all of the compiled .dso files in your project prior to backing up your project. You can remove this if you want to back those up as well, but it will decrease the backup time by deleting the dso's first. Less files to copy.

IF EXIST B:\Backups\Torque\MyGame\%date:~0,3% RD B:\Backups\Torque\MyGame\%date:~0,3% /S /Q
next we check if the backup directory already exists. The %date:~0,3% returns the date, trimmed down to just three characters. if you execute this on Sunday, then your directory would be named MyGame\Sun.
if Backups\Torque\myGame\Sun exists, it deletes the directory. /S deletes all the sub folders and files, /Q puts it in quiet mode. If you don't use the /Q then you will be required to enter Y at the command promt to give the RD command permission to delete all files.

xcopy C:\Torque\MyGame\* "C:\Backups\Torque\MyGame\%date:~0,3%\*" /y /s
xcopy copies all the files and folders in your MyGame into your backup folder with the name of the date. the /y suppresses the promt to overwrite files, which we really shouldn't have that problem anyway because we are deleting the directory if it exists. /S copies all the subfolders and files.

net use b: /DELETE
If you are copying to your local harddrive you won't need this command. This will disconnect you from your server once the script has completed.

#1
11/11/2007 (3:01 pm)
this is very usefult to me, but I am concerned about the DELETE commands - what are they doing? Deleting the original?
#2
11/11/2007 (4:02 pm)
@Andy: The "del /s *.dso" is just deleting the .dso compiled scripts.
#3
11/11/2007 (6:36 pm)
and the /DELETE ones just un-map the remote shared resource (the b: unit in this case).
#4
11/11/2007 (8:23 pm)
@Andy
Shawn is correct, the
del /s *.dso
just deletes all of the compiled torque scripts in your working project directory. It is up to you, you can not add this line if you want.

and the
net use b: /DELETE
just deletes the network connection to your server if you are connecting to a server. If you are not connecting to a server and backing up your project, just omit both "net use" commands.

To help make you feel better, make a manual backup of your project and store it someplace until you have your script working the way you want it to.
#5
11/11/2007 (9:13 pm)
Why don't you just use subversion?

Edit: Or any other SCM system ... ;-)
#6
11/11/2007 (10:12 pm)
There where a couple different reasons. I read a resource on here about setting up subversion with Apache and Tortoise, but my Apache kept giving me an error and I could never get it setup, so I just abandoned it and went with this setup. I even went online and managed to fix some errors, but for every error I fixed I had another issue come up and it wouldn't work.

I tried looking for an all in one solution, but couldn't find anything. I'm open for suggestions!
#7
11/12/2007 (3:44 am)
Johnathon: Have a look at "svnserve" that comes with subversion. It's really simple to setup on Linux, or windows and avoids having to use Apache. You just create your repo, make a minor change to the conf/svnseve.con:

[general]
password-db = passwd
realm = PickAName

anon-access = none
anon-read = none
auth-access = write

Then setup a passwd file

[users]
gary = mypasswordhere

For additional info svnbook.red-bean.com/. I find having SVN access even for projects where it's just me, is highly useful. Aside from the check-in to a remote machine acting as a first backup, you never know when you might want to allow someone else access to your repo.
#8
11/12/2007 (3:56 am)
Two words... Subversion Sux.

We lost 3 days at work last week because the branch we were working on got mangled merging from the trunk. We will never work on a branch again...
#9
11/12/2007 (4:47 am)
Version control is nice - but you'll still need a backup of your repo. I'd say if you are working alone, I'd weigh the benefit of version control against the potential pitfalls (if you don't do things in the order that SVN likes to see things done, you might end up with a headache.)

I agree with Andy, SVN sucks. But sometimes... SVN unsucks itself -- when it saves your ass or enables your team to collaborate on a project, see what was done when, and revert to any version of any file. NTM the integration with TRAC, which in my experience is one of the greatest things about SVN:)

I'm hoping to see SVN be a little more flexible / graceful in the future. Things can get ugly if a user (or in rare cases, SVN itself) gets squirrely.
#10
11/12/2007 (5:00 am)
Yeah I wouldn't mind using SVN on my own games - currently I am just winzip'ing my work and using Winmerge to keep my two computers in sync - but I'm afraid I'll rely on it to work - ALL THE TIME - and that one day I really need to restore it'll say "ummm what revision are you talking about?"

I just can't trust it. But I do like team collaboration on such things - I occasionally branch out and employ a few people which is when it would count... hey this is a bit off topic - sorry Johnathon.
#11
11/12/2007 (6:46 am)
Subversion has a flaw or two, but nothing compared to the loss of a project. Yes, merging branches into trunks can be a messy ordeal, which is why I use an unorthodox approach to source control management. I still use Subversion, but without branches.

In the spirit of this blog, I posted a follow-up to my Source Control How-To resource with a nightly build/backup system using Windows, batch files, and Subversion. It is similar to this blog, except it incorporates Subversion to do a checkout as well.

@Johnathon - I take it you found errors following the my resource? No one else claimed to have run across any Apache errors, so I'm interested in what you might have run into. If you e-mail me, I'll help you out one on one with the error, as I think keeping your projects under source control is a good idea (especially with what you are doing).
#12
11/12/2007 (10:33 am)
I have long opted for a combination approach:

> Subversion
> Tortoise SVN (makes using SVN a breeze from Windows Explorer right click context menus)
> WinMerge (alleviates all merging/branching issues)

I use branches and multiple repositories extensively and have never (knock on electrons) had a problem with SVN corruption.

Here's the key:

DO IT YOURSELF - don't allow SVN to merge branches for you and you won't have any troubles. SVN does an adequate job of this, way better than CVS ever did, but for complicated projects - just don't trust it. And there's no need to because WinMerge makes it easy to do it yourself.

1. Check out a working folder of your trunk
2. Check out a working folder of your branch
3. Do a compare between the two with WinMerge
4. Merge the branch into the trunk
5. Commit the trunk

I do this everyday as a matter of routine and have never had a branch corrupt a trunk.

If you're having install problems for subversion check out VisualSVN Server for a brainless install. It installs its own copy of Apache on port 81, setts up the repo folder for you and gives you a real easy to use security UI (which can be the biggest pain for new SVN users).

Edited: Fixed bad link.
#13
11/12/2007 (10:58 am)
The thing about SCM systems in general (e.g. not just subversion) is that, like every other developer tool, you really have to know how to use them to get anything out of them. The best way to get that experience is to use a well run repo that's managed by someone who knows what they're doing. You can also learn by doing and by reading guides on the net, but that is much slower and will lead to lots of messed up repos until you find your feet.

A well run repo will save you a lot of time, hassle and premature hair loss. Backing up by hand, even with the use of batch files, is error prone, time consuming and seriously wasteful of HD space. That said, at the end of the day, everyone has their own preferences. Personally, it is completely incomprehensible why anyone would not want to use SCM :)

For those having problems with merging, what Jeff Leigh suggests above is really good advice. Beyond Compare is better than WinMerge though ;-) Other than bugs in early versions of svn, and a couple of cases of stupid user syndrome, I've havent had any problems with svn either.

It's also worth pointing out that Subversion is not the only SCM solution. Perforce is a good commercial one; though prohibitively expensive for indie teams, there's a free version that would likely suit a one man "team" quite well. I'd suggest poking around the net and trying some out. Whatever you do though, stay away from Visual SourceUnsafe ... it has that universally recognised nickname for a reason :)

T.
#14
11/12/2007 (2:39 pm)
I would like to second what Jeff Leigh (Jeffer) and Tom Bampton said. But, I would like to add something else... (from my experience)

SCM is a MUST for a developer. What to use - it's like "what you prefer: Opera, FireFox or IE". Find the one that you can feel "safe" with.
First, I started with "classic" CVS.. Later moved into SVN. Set up a separate server just for SVN. At first - I used separate repo-s when making "branches"... While I grow at understanding on "how all of this works" I found this really useful for myself. A good planned project can live a long life on SVN (assuming you have a failover-backup like on tapes or external HDD).

For now (as of today) I can't even imagine to work without SVN. Even all of my "notes" (.TXT files) are SVN-ed :)

@Johnathon: you can add to your instructions the /H parameter, it will tell the xcopy to include ALL files (including marked as hidden/system). And the /G can be useful too (Allows the copying of encrypted files to destination that does not support encryption)
:)
#15
11/12/2007 (4:06 pm)
It was Tortoise that caused the problem when we merged from the trunk. Rule of thumb is do all your merging and branching via a Putty shell into Linux or via the command line. Tortoise seem reliable when doing simple checkin/checkout/updates.
#16
11/12/2007 (5:48 pm)
Wow, this was a good read tonight lol. Thanks everyone for the replies and suggestions.

@Gary Preston:
I will try svnserv if I can't get apache up and running.

@Andy Hawkins
No problem :D

@Michael Perry
yes, it was your resource I was following when I tried to setup my subversion, I think the problem was not in your resource, but in the fact that I couldn't find the same version's of Apache and subversion that you where using.
Your Version->My Version
Apache 2.0.59->2.2.6
Subversion 1.3.2->1.4.5

I don't remember exactly what the error was, something about not being able to use an ip of 0.0.0.0:80, but I will re-install apache and see what the error actually says and fire you an email. Thanks for the help!

@Jeff Leigh
I will look into that as well if I can't get Michael's resource to work.

@bank:
From what I've read it sounds like SCM really helps out with the project management. Thanks for the tip on the /H and /G parameters. I'll be using my script until I can get subversion working.
#17
11/12/2007 (6:20 pm)
Johnathon:
you should be able to just create a new "repo" by TotroiseSVN without using any apache/subversion (on Windows).
Install TotroiseSVN, reboot if needed. Create a folder (e.g. C:\repo\), right click on it and choose from menu "TotroiseSVN" and then "Create repository here..." submenu option... then... do what you want.

I would recommend you to start playing with TotroiseSVN first, create a few empty repo's, do import/checkout/etc. And, btw, you can have this folder on network-shared drive and can access from multiple computers.
This is "aSap" (as Simple as possible) case of getting "in touch" with SVN basics (windows-friendly behaviour). And yeah, there are a lot of different manuals and HOWTO's on internet about SVN.
The TotroiseSVN is just about "visualization" - it can really help you to start with SVN itself. What you will use at the end - is up to you. Read what others said up on the thread here (incl. Andy's comment about Tortoise being not so good sometimes).
#18
11/12/2007 (6:38 pm)
Bank:
Thanks, I'll spend tonight messing with totroiseSVN, I have it installed just haven't used it. I noted what Andy said about it not being to good with branching, I will keep this in mind. I would assume as long as you know what you are doing it, and do it manually instead of allowing SVn to automate the trunks, you would be ok?
#19
11/12/2007 (6:40 pm)
Johnathon - this is your problem:

Your Version->My Version
Apache 2.0.59->2.2.6
Subversion 1.3.2->1.4.5

Stay away from Apache 2.2.x unless you know what you're doing with Apache. It's too new and there are issues (peculiarities) with SVN 1.4.5 - they're both too new and untested in my opinion.
#20
11/13/2007 (3:56 pm)
Jeff:
Thanks, Michael worked with me last night and we got it setup and running on my machine with the 2.0.59 version of Apache. W00t! I feel like I just pimped my computer.