As the previous poster mentioned, Sybase is a company not a product,
but since we ASE users tend to be the folks who forget this most
often, I'll assume that you're running ASE 12.5.x or newer and that
you can actually compress the dump on the fly. One syntax supported
for this is:
DUMP ... WITH COMPRESSION=n ...
where N is an integer 1 ... 9 I believe. At level 4 (our default) we
tend to get the best ROI for time (lost) and space (gained) until the
database gets quite a bit bigger than yours currently is. On our
(Linux) platform at least, YMMV.
Once you've compressed it, you're right tar's -z or -Z flags won't
squeeze much more out of it since they likely use the same well-known
algorithms.
I don't understand why rsync is not working for you, and I'm not
entirely sure what you expect to get by "delta-ing" the backups, but
you may be able to use the "sum" command in Unix-like environments to
check if the file is identical to its previous iteration.
If you're allowed to use rsync, then the security built into scp will
definitely cost you performance-wise. Not only should rcp or rsync be
faster, but so will
ftp.
Finally, for a warm-standby solution (not a replacement for backups,
but it may solve some of the issues you're trying to solve with them
currently) have you tried RepServer or ASE replicator?
Keith
On Oct 14, 3:29 pm, m <superve... at (no spam) gmail.com> wrote:
We have a database that when dumped with the dbbackup command is a
67gb .db file and a 28gB .log file . It's becoming somewhat difficult
to manage the offsite backups, which are now done weekly via scp. Tar
does not provide any compression on the .db file. The server the db
runs on is windows 2003 and all backup systems are nix based.
1. In sybase is it possible to delta the dumps. I can't find if
dbbackup is a copy of the .db file and .log in use or if it is a sql
dump. Using rsync on a file that large does not work. I would have to
use something that can pre-calculate the difference and then upload.
What recommendations do you have for offsite backups/copies. Our link
is a 10mb symetrical to our off-site server.
2. Our next step if we can't figure this out is to backup our server
at the block level live, but that might still create issues not only
in storage, but if the dbbackup dumps are too different, as it will
still require uploading a significant amount of data. Additionally,
storage costs will skyrocket for us, as we will be backing up more
data than needed.
