A good free backup progie like Rsync

Hi all I need a free program to backup a ubuntu server for my school class,
it has to be as good or better than Rdiff and Rsync the server will use SSH,
MYSql and be a file and web server and do a couple of other things. I need
it to be either a gui or text box program.

Thanks
GK

On Mon, 26 Oct 2009 16:25:26 +1100, Gabriel Knight wrote:

> Hi all I need a free program to backup a ubuntu server for my school
> class, it has to be as good or better than Rdiff and Rsync the server
> will use SSH, MYSql and be a file and web server and do a couple of
> other things. I need it to be either a gui or text box program.

Bacula?

"Gabriel Knight" <(E-Mail Removed)> writes:

>Hi all I need a free program to backup a ubuntu server for my school class,
>it has to be as good or better than Rdiff and Rsync the server will use SSH,
>MYSql and be a file and web server and do a couple of other things. I need
>it to be either a gui or text box program.

Why not use rsync? I can assure you that it is as good as rsync.
And why not make it a cron job-- then you do not even need a gui or text
box for it.

terryc wrote:

> On Mon, 26 Oct 2009 16:25:26 +1100, Gabriel Knight wrote:
>
>> Hi all I need a free program to backup a ubuntu server for my school
>> class, it has to be as good or better than Rdiff and Rsync the server
>> will use SSH, MYSql and be a file and web server and do a couple of
>> other things. I need it to be either a gui or text box program.
>
> Bacula?

Amanda? I have always been happy with it. For any backup utility that
works on the file level the MySQL database will have to be dumped to a
file prior to running the backup.

Günther

On 2009-10-26, Günther Schwarz <(E-Mail Removed)> wrote:
> terryc wrote:
>
>> On Mon, 26 Oct 2009 16:25:26 +1100, Gabriel Knight wrote:
>>
>>> Hi all I need a free program to backup a ubuntu server for my school
>>> class, it has to be as good or better than Rdiff and Rsync the server
>>> will use SSH, MYSql and be a file and web server and do a couple of
>>> other things. I need it to be either a gui or text box program.
>>
>> Bacula?
>
> Amanda? I have always been happy with it. For any backup utility that
> works on the file level the MySQL database will have to be dumped to a
> file prior to running the backup.

Which makes rsync or rsnapshot perfect for the job. Do the mysql
backup first, then the rsync or rsnapshot, all from an automated cron
job. No need for any UI at all.


--
Joe - Linux User #449481/Ubuntu User #19733
joe at hits - buffalo dot com
"Hate is baggage, life is too short to go around pissed off all the
time..." - Danny, American History X

Gabriel Knight wrote:
> Hi all I need a free program to backup a ubuntu server for my school class,
> it has to be as good or better than Rdiff and Rsync the server will use SSH,
> MYSql and be a file and web server and do a couple of other things. I need
> it to be either a gui or text box program.

Grsync.

Keith Keller wrote:
> On 2009-10-26, David Brown <(E-Mail Removed)> wrote:
>> Running an rsync on a database's data directory will give you a snapshot
>> of the database files at the time. If you were then to stop the
>> database server and copy those files back again (simulating a restore),
>> and start the server, it would seem to the server that it had suffered a
>> system crash or power out, and it would recover the data using the
>> journals and logs in these files. You will very likely lose some of the
>> latest changes to the database, and it's conceivable that there might be
>> inconsistencies due to writes to the files during the time taken to do
>> the rsync, but the server should fix these on startup. Whether this
>> level of backup is acceptable or not depends on the sort of data you are
>> dealing with, and how often it is changing. Proper dumps are normally a
>> better choice, but simple file copies are better than nothing.
>
> In my opinion the most important part of the above is "Proper dumps are
> normally a better choice". I would expand that to *much* better. If
> your database is small, you might as well just dump it. And if it's
> large, then a filesystem rsync (without table locking or similar) might
> result in odd issues with your data that might not be resolved by the
> dbms' recovery system.
>

It depends somewhat on your needs, your database usage, and your
database server. I don't know about MySQL, but postgresql seems to be
good at working with such straight file copy backups. If you don't
write much to your database, your chances of a corrupt copy become
smaller (and then you just use the previous backup instead). If you are
using a system like rsnapshot with multiple backup copies that are
hardlinked when the files are unchanged, you get very small incremental
costs per backup. With monolithic dump files, even a single change to
the database means that the whole file must be saved for each backup
(though rsync will still minimise the traffic transferred in the copy).

You can take it a stage further by putting your database files on an LVM
volume and doing an LVM snapshot, which you then use for the backup.
Then your files are consistent exactly as though the power was turned
off when the snapshot is taken - and a database server worth the name
should be able to recover from that.

> For taking a backup of MyISAM tables in mysql, you can use mysqlhotcopy,
> which properly locks the tables, copies the raw database files, then
> unlocks the tables. This way you get a consistent database snapshot
> without possibly having to generate and store a full text dump, which
> might take longer and take more disk space. (The downside is that,
> since the backup is stored as binary data, not text, a backup system
> that works off of diffs won't be as efficient.)
>

You get a fully consistent database snapshot in this way (and as I said,
proper dumps like this are normally the best choice). But you have
several downsides. First, you have extra processes to run and
synchronise (not a problem with cron and a script, but it might be an
issue for people wanting a simpler system, or if the backup is initiated
from a different computer). Second, you are locking all the tables
during the backup - that may or may not be an issue. Thirdly, as you
say your backups may take more time, and they take more space since you
can't take advantage of hard-linked copies (diff-based backups are
horrible - I wouldn't recommend them).


It's all a matter of balancing your needs. If you are already doing an
rsync backup of everything else on the machine, including the database
files is very simple. It may be good enough for you. Doing database
dumps is the "right" way to do the backups, so that should be the method
to use unless you have good reason not to. But wanting a simple and
easy solution without having to learn about dumps may well count as a
good enough reason.


Whatever method you choose, do a practice restore to make sure you can
recover your data!

On Tue, 27 Oct 2009 11:04:15 -0700, Keith Keller <kkeller-(E-Mail Removed)> wrote:

>On 2009-10-27, David Brown <(E-Mail Removed)> wrote:
>>
....
>> If you don't
>> write much to your database, your chances of a corrupt copy become
>> smaller (and then you just use the previous backup instead). If you are
>> using a system like rsnapshot with multiple backup copies that are
>> hardlinked when the files are unchanged, you get very small incremental
>> costs per backup.

I'm using rsync and hard-linked backups run from a cron job each 30 min,
with another daily cron job eating the backup tail -- I think at age 90
days. Only problem I had was slocate filling the /var partition -- so I
uninstalled slocate, I don't use it anyway.
....
>> It's all a matter of balancing your needs.
>> Whatever method you choose, do a practice restore to make sure you can
>> recover your data!
>
>Double-plus-yes to the above! In addition, do a practice restore to a
>different machine if at all possible.

Yes, test the restore ability _before_ you need it, way back I discovered
a booboo in a backup script -- it looked normal but was overwriting files
with altered most recent, instead of saving the altered file -- easy to
fix. But the backup was bust at the time I needed a file and found the
buglet instead.

Grant.
--
http://bugsplatter.id.au

In article <4ae532d0$0$70417$(E-Mail Removed)>,
Gabriel Knight <(E-Mail Removed)> wrote:
:Hi all I need a free program to backup a ubuntu server for my school class,
:it has to be as good or better than Rdiff and Rsync the server will use SSH,
:MYSql and be a file and web server and do a couple of other things. I need
:it to be either a gui or text box program.

If you want something like rdiff and rsync, then rdiff-backup might be a
good match. It combines the features of a mirror and an incremental
backup, so you can restore to any previous backup point. The increments
are kept as a series of reverse diffs from the current mirror. Syntax
is similar to rsync, and librsync is used to generate efficient reverse
diffs. Biggest disadvantage is the difficulty of deleting that
multi-gigabyte file that accidentally got included in your regular
backup. Learning curve can be a bit steep at first.

http://www.nongnu.org/rdiff-backup/

--
Bob Nichols AT comcast.net I am "RNichols42"

On Mon, 26 Oct 2009 20:52:26 +0100, David Brown wrote:

> Gabriel Knight wrote:
>> Hi all I need a free program to backup a ubuntu server for my school
>> class, it has to be as good or better than Rdiff and Rsync the server
>> will use SSH, MYSql and be a file and web server and do a couple of
>> other things. I need it to be either a gui or text box program.
>>
>>
> As others have said, the obvious choice here would be ... rsync.

*sync isn't a abckup system. It is just a copy system.