See date(1), tar(1), scp(1). You could adapt it for FTP. Schedule it with cron(8) and you will get an email of the output from scp.Code:DAY=`date "+%A"` tar jcf $DAY.tar.bz2 <target-dir> && scp $DAY.tar.gz <user>@<host>:
Can anyone recommend any good Linux based website backup solutions? I have a hosted server where I host a course website- the server runs Ubuntu and the hosting provider also provides dedicated FTP backup space.
On this basis it'd be great if there was a solution that I could run on the server that incrementally backs up the website files and SQL databases on a schedule to this FTP space. Ideally it'd manage versions, keeping changes and deleting versions older than x days.
I also have a Open Solaris server hanging off a Be line in the apartment and to be really paranoid it'd be great to back the website up to a folder here as well. This could either be the same solution (although I guess maybe I'd have to invest in another SSL cert for the incoming connection from the website server) or something initiated from the Solaris server.
Of course there is nothing stopping me simply using Robocopy (someone told me there is an equivalent for Linux) to replicate the FTP storage space with the original backup. In that case it'd be good if there was some kind of monitoring I could put in place to let me know if files haven't been written in x days (or a daily e-mail to say backup has run) so I can be confident backup will be there should the worst happen.
At present I use Site Vault which is Windows Based and has limitations for power user use- it's only possible to roll back an entire backup (think Windows Restore Points) rather than reverse one specific change. Since I'm going to lose Windows Server anyway (won't be renewing TechNet this year) this time seems ripe for a change.
See date(1), tar(1), scp(1). You could adapt it for FTP. Schedule it with cron(8) and you will get an email of the output from scp.Code:DAY=`date "+%A"` tar jcf $DAY.tar.bz2 <target-dir> && scp $DAY.tar.gz <user>@<host>:
pwds (31-01-2010)
Depending upon how much data we're talking about and how much changes per day you may want to use rsync to only transfer the changed files each day rather than make the system work creating the gzipped tarball.
For example, we have a few sites with large (+300GB) web directories and it isn't viable for us to tar that every night and transfer it so we have 'days' as powdarrmonkey recommends directories on the remote storage and then we literally rsync the changes each day into the relevant day so you have a weeks worth of back ups with only diffs being carried over.
If you don't have a lot of data I'd stick with powdarrmonkey's advice but if you like I can go into this further.
PS. If you're using SQL you're going to want to dump those databases before you scp/rsync, something like mysqldump in the schedule or automysqlbackup to look after that for you.
I personally use backuppc installed on a debian box here (sounds like the same role as your OpenSolaris box) which pulls down back ups (rather than having the web box push) regularly and looks after all that for me. But with your host providing FTP back up you might as well use it![]()
pwds (31-01-2010)
I like the idea of pulling down the backup to the server here and also copying it to the FTP from the server. I'll explore RSYNC for changing files as I'd most likely want to restore individual files anyway.
kmount: good point, it was midnight and I'd assumed a small amount of data, sorry
rsync is indeed much more efficient for just moving changes.
For a site I help to manage (non work) I use a linux app called ftpcopy which is sitting on my NAS box, and just copies down files which have changed in the last 2 days, and mysqldump to take a copy of the db.
Running both daily, I get a full copy of the site, always up to date.
I probably should say that this is my belt and braces version of making sure that we're not screwed if the backup somebody else reckons to have set up turns out to be rubbish!
pwds (01-02-2010)
There are currently 1 users browsing this thread. (0 members and 1 guests)