Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm making the move from VPS to Dedicate server. Unfortunately, most dedicated servers do not provide server backups like managed VPS's do and I really like the piece of mind of having a backup of all my scripts/files if something does go wrong (it has before)

So, the question is; is it possible to create "Snap shots" of certain directories daily which are saved on the same server, but in a different folders.

Understandably, these backups will not protect from external disaster. I am more looking for protection from any damaged caused by malicious scripts/hacking etc.

Thanks in advanced.

share|improve this question

You're probably looking for something like Webmin:

It's a mandatory part of my CentOS server setups. It's really easy to install and makes server admin a breeze, especially backing stuff up. Take a look at the documentation here:

share|improve this answer

is it possible to create "Snap shots" of certain directories daily which are saved on the same server, but in a different folders. ... for protection from any damaged caused by malicious scripts/hacking etc.

Yes, any one of the many revision control software tools that will do exactly that.

I use Mercurial ("hg"), often with the pretty gui TortoiseHg frontend.

On many of my servers, there exists one folder(*), perhaps "/var/www/", that contains everything I want to back up -- settings files, templates, custom server-side cgi-bin scripts, custom browser-side .js scripts, .html content, etc. (Everything else on the machine is boilerplate operating system and application stuff. If that stuff gets damaged, I'd probably wipe it and install the latest version of it, rather than try to revert to the old, obsolete version I was using).

When I first set things up, I cd to that folder and do the one-time setup

hg init
hg add
hg commit -u dc -m "initial setup"

The "init" line creates a ".hg/" folder that, someday, will store compressed snapshots. (hence the name of a popular Mercurial tutorial, ). The "add" line and the "commit" line, by default, scans every file every file in that folder, no matter how deeply nested in sub-sub folders, and puts a (compressed) copy into that ".hg/" folder.

When I suspect damage or other change to the working files (and assuming the ".hg" folder, containing all the snapshots, is undamaged), I type

hg status

which tells me exactly which files have changed, no matter how deeply nested in some sub-sub-folder, then I type

hg diff

which tells me exactly what changed in each file.

If I don't like what I see -- it's malicious modifications, or more commonly, it's my own silly edits that I now regret making, I type

hg revert --all

to revert all changes back to the most recent commit.

If I do like what I see -- I've tweaked something that actually makes it better -- I type something like

hg add
hg commit -u dc -m "tweaked .htaccess so we now have Clean URLs."

with a comment that hopefully describes why I made these changes. (There are ways to revert only some of the files, and to commit only some of the files, and even ways to commit only some of the many changes that were made to a single file -- see the documentation for details).

Perhaps you would rather have a cron job that daily does something like

hg add
hg commit -u mr_backup -m "cron automated snapshot of the server."

A compressed snapshot of every version that has ever been committed stays in the ".hg/" folder. There's a "hg update" command to revert to any committed version. There's a "hg diff -r 1:2" command to see exactly what changed between the first commit and the second commit.

more complex situations

(*) Often there is only one folder I want to back up ( "/var/www/" ). However, sometimes I have a more complex situation -- the files I want to back up are scattered in a bunch of different folders, and the only common folder between them is the root folder "/", and I don't want to put the ".hg/" repository in the root folder "/.hg/" .

There's probably a better way to handle it, but what I'm doing right now is:

  • I create a special user named "MrBackup" that has read-only permissions for all the files I want to back up.
  • I set things up so every folder I want to back up appears as a subfolder of /home/mr_backup. I currently have a random mixture of:
    • Some files are actually in MrBackup's home folder, and then the other place they "need" to be has a soft-link to them.
    • Some files have a hard link to them in both places -- the place they "need" to be, and also somewhere in MrBackup's home folder.
    • A cron script periodically copies some files from the "live" location into a backup folder in MrBackup's home folder, perhaps dumps a SQL database from another server into a dump file in MrBackup's home folder, and also makes a backup of the cron script itself ( "crontab -l > /home/mr_backup/backup/crontab.txt" ).
  • Often I want to back up almost everything in some folder P, except for a "cache/" subfolder that I don't need to back up, since it will be automatically regenerated if needed. I use ".hgignore" to exclude the cache subfolder.
  • Then I use Mercurial, as above.
  • When the files generated by the cron script don't look right, after I do a revert, I need to take some extra steps to somehow push the "good version" back to the "live" location.

p.s.: On a machine in a different city from my server, I occasionally fire up TortoiseHg workbench and click the little button that, behind the scenes, runs

hg pull

(and asks me for Mr Backup's password) to get an off-site backup of everything that has been committed to the repository.

Rather than make edits live to the production server, it's usually better to make the edits on some other machine, then commit them and

hg push

them to the production server.

The ".hg/" folder keeps growing -- very slowly, because it only saves files that change from one commit to the next, and even those relatively small changesets are compressed before they are stored.

There's probably a better way to deal with this slow growth, but what I currently do is:

After I "hg commit" the current version and then "hg pull" onto my off-site backup machine, once a year I delete the server's ".hg/" folder and use "hg init" to create a fresh, new, empty ".hg/" folder, and then I commit the current version. (The last version of the 2014 off-site backup repository should be identical to the first version of the 2015 off-site backup repository).

share|improve this answer

Your Answer


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.