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.

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.

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?

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.

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.

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.

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.

On 2009-10-26, David Brown <david.brown at (no spam) hesbynett.removethisbit.no> 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.

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.)

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).

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.

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!

On 2009-10-27, David Brown <david at (no spam) westcontrol.removethisbit.com> 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.

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.

On 2009-10-27, David Brown <david at (no spam) westcontrol.removethisbit.com> wrote:
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.

I don't know if this is true with newer versions of postgresql, but the
versions I've used, the data store was not portable across different
architectures. Indeed, there was no guarantee of portability even
across different machines on the same architecture, even using the same
version of PostgreSQL!

(I think that I've done it, but that would have been a long time ago.
I did get caught by this issue, though: my main home server's power supply
died, and the only other machine I had available was a ppc box. My naive
solution, simply using the data store from the old machine's hard drive,
didn't work, and I had to resort to an old dump (because I'd recently
broken my backup script). Fortunately this was not a huge problem for
me, but I could imagine it being a big problem if you had no dumps at
all.)

So I think it's not wise to depend on this mode as a primary backup--it
could serve as a desperation backup, but the primary backup should be a
proper dump (or mysqlhotcopy if you can and desire).

For MyISAM tables, MySQL works fine with filesystem backups; I believe
these files are portable across architectures, but don't quote me on
that. I don't know how portable filesystem snapshots are for InnoDB
tables.

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).

This is all true, but I don't see a way to reliably get a good backup
otherwise. And you'll only have real difficulties if your database is
quite large--most typical dbs should not create enormous dump files
anyway.

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.

Well...I think that anyone intent on using a database regularly should
not allow themselves to get lazy and rely on filesystem backups. They
should start the ''right'' way, and only use a filesystem backup if they
really don't care all that much about their databases in the first
place (or can recreate it quickly from what they already have on their
filesystem).

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.

--keith

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.

And a backup is not a copy?