When going the rsync route, you can do it like this: first use rsync on a life database, then stop the database, do another rsync to the same destination, and restart the database. The second rsync should be much faster since most of the files won't have changed and don't need to be copied again. On 02/23/2016 05:57 PM, Martin Kersten wrote:
Hi
Under the assumption that there is a small timeslot and your database doesn't grow too fast during a day, then simply stop the server and run a rsync over the dbfarm (bats + sqllogs) You might use rsync without stopping the server to see the time required for such action and if it fits your timeslot boundaries.
regards, Martin
On 23/02/16 16:48, Sjoerd Mullender wrote: On 23/02/16 15:45, Dennis Pallett wrote:
Hi all,
Is it possible to create a file system level backup of a running MonetDB database? What are the downsides of doing this?
For what it's worth, our databases are generally never updated outside of pre-fixed windows so only SELECT queries will be executed during any file system level backup.
Best regards, Dennis Pallett
At any point in time, the disk image of the database should be consistent. All committed transactions should be safe on disk. But MonetDB makes use of atomic file system operations to commit transaction s.
Since making a file system backup takes time, it could start before a transaction commits, and end after. If this happens, there cannot be any guarantees about the backup. Another potential for problems is when the server decides to do some database maintenance. Every once in a while, the write-ahead log (WAL) is cleaned up. It this happens during a file system backup, again there are no guarantees.
If neither of these events (transaction, WAL cleanup) happens during the backup, you're probably ok. But this is not something we can guarantee in any way, so to be sure of a proper backup, you should also create a sql-level backup (msqldump) in case the file system backup gives weird results after it is restored (which one of course hopes is never needed).
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
-- Sjoerd Mullender