Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

A site I just became in charge of uses a really simple two folder structure to host the dev site and the QA site. The sites are hosted on the company servers so I just have the sites' folders mapped on my desktop.

I would like to run some kind of backup scheme, but I am finding it hard to think of a way to do this effectively.

The problem is that we aren't using any revision control software, and since the servers aren't controlled by me, I don't think I will be able to implement anything like that. Or could I?

The entire site is static too, so no DB's or anything besides html, images, PDFs, etc.

share|improve this question
    
What would you like to backup? If you are using some revision control software (SVN, git, etc..), you could back up only that and the DB dumps (and maybe some external library/file that doesnt need versioning). –  milo5b Oct 10 '12 at 8:15
    
The problem is that we aren't using any revision control software, and since the servers aren't controlled by me, I don't think I will be able to implement anything like that. Or could I? –  novicePrgrmr Oct 10 '12 at 8:28
    
The entire site is static too, so no DB's or anything besides html, images, PDFs, etc. –  novicePrgrmr Oct 10 '12 at 8:30
    
Do you have root access? –  Anagio Dec 9 '12 at 10:39
add comment

2 Answers 2

up vote 1 down vote accepted

I would implement revision control if I were in you. You might have to change a couple of things since it's all html, maybe making some dynamic code for paths or similar problems that might occur. The production server should not have the revision software's directories in its tree, so it could be done even if you do not control the servers (although it might be more problematic/slow to deploy code). If you could access the servers, I would keep dev and QA folders under version control, then a deployment script from QA to production. In case you couldnt, you could just run deployment scripts from your local machines to your live server (so deploy local.dev to live.dev, local.qa to live.qa, and probably live.QA to production). Doing so you would need to backup only the version control folder (that can be on any server you'd like).

If it's sounds too overkill and you can run unix utils on your server, you might have a look at rsync to backup incrementally (this utility would also help deployment speed)

share|improve this answer
    
Yeah I like both ideas, but it seems crazy complicated to implement. I have never used SVN, git, or any other revision control. –  novicePrgrmr Oct 10 '12 at 12:43
    
It's not very complicated, but depending on your set-up could get slightly more complicated. To have a basic version it's probably 4-5 commands - and there's plenty of documentation on the net (at least for git and SVN). And if things go wrong we are always here :) –  milo5b Oct 10 '12 at 13:42
    
True, I will look into it and see if its possible. The only thing is that I don't even have access to the live folder. Once I drop something into QA it gets taken through a security check and then posted live. Would that be a problem? –  novicePrgrmr Oct 10 '12 at 14:46
    
You've been awesome by the way. Thanks a ton! –  novicePrgrmr Oct 10 '12 at 14:47
    
No problems. It would depend on the scripts that does the checks and all, but hopefully it will be alright (I guess you need just to make sure in QA you have only files relevant to the project, and not to the revision control software - but it's just a guess as I don't know how your system is set-up). –  milo5b Oct 10 '12 at 15:50
add comment

Are they running Linux servers? You can do rsync remotely over SSH to your computer and setup a cron job to backup all the files on a schedule

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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