You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by kosurusekhar <ko...@gmail.com> on 2014/11/04 06:54:29 UTC

Derby online backup with huge database

Hi All,

We implemented to take the derby online backup when ever our application is
launching. It is working fine. But in production the database grows more
than 2GB. It is taking  more than 7 to 10 minutes to take the backup. 

Is this behaviour is normal with Derby database?

Is there any thing need to configure/implement to speedup the backup
process?

Please advice me in that.

Thanks in advance.

Regards
Sekhar.



--
View this message in context: http://apache-database.10148.n7.nabble.com/Derby-online-backup-with-huge-database-tp143121.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.

Re: Derby online backup with huge database

Posted by kosurusekhar <ko...@gmail.com>.
Hi Peter,

Thanks for your reply, 

Sorry for my late reply.

I dig into my source code and observed that database is taking around 2
minutes of time to take the backup. After this our application is making it
zip. It is consuming another 3 to 4 minutes. OS copy command also is taking
around 1.5 minutes like that. 

As per Brett, when data grows automatically derby will take time do online
backup.

@Brett, we using windows. Now we are using Linux as well.

If is there any way to minimize this means suggest me.

Thanks.



--
View this message in context: http://apache-database.10148.n7.nabble.com/Derby-online-backup-with-huge-database-tp143121p143220.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.

Re: Derby online backup with huge database

Posted by Peter Ondruška <pe...@kaibo.eu>.
How long does it take to copy database to backup destination using
operating system copy command?

On 4 November 2014 06:54, kosurusekhar <ko...@gmail.com> wrote:

> Hi All,
>
> We implemented to take the derby online backup when ever our application is
> launching. It is working fine. But in production the database grows more
> than 2GB. It is taking  more than 7 to 10 minutes to take the backup.
>
> Is this behaviour is normal with Derby database?
>
> Is there any thing need to configure/implement to speedup the backup
> process?
>
> Please advice me in that.
>
> Thanks in advance.
>
> Regards
> Sekhar.
>
>
>
> --
> View this message in context:
> http://apache-database.10148.n7.nabble.com/Derby-online-backup-with-huge-database-tp143121.html
> Sent from the Apache Derby Users mailing list archive at Nabble.com.
>



-- 
Peter Ondruška

RE: Derby online backup with huge database

Posted by "Bergquist, Brett" <BB...@canoga.com>.
Also, what OS are you running?  

We have a Derby database that is about 300GB and the online backup would slow down operation of the system too much and take too long to perform.    Fortunately we are using Solaris 10 with the database being on a ZFS pool and what we ended up doing is to do a "freeze" of the database, take a ZFS snapshot of the filesystem, and then "unfreeze" the database.   Then we backup the database from the ZFS snapshot at leisure using "tar" and "gzip" and offload that to another server.

Now some of the Linux based systems have ZFS so we will start to be able to support those as well.  

-----Original Message-----
From: kosurusekhar [mailto:kosurusekhar@gmail.com] 
Sent: Tuesday, November 04, 2014 12:54 AM
To: derby-user@db.apache.org
Subject: Derby online backup with huge database

Hi All,

We implemented to take the derby online backup when ever our application is launching. It is working fine. But in production the database grows more than 2GB. It is taking  more than 7 to 10 minutes to take the backup. 

Is this behaviour is normal with Derby database?

Is there any thing need to configure/implement to speedup the backup process?

Please advice me in that.

Thanks in advance.

Regards
Sekhar.



--
View this message in context: http://apache-database.10148.n7.nabble.com/Derby-online-backup-with-huge-database-tp143121.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.