Subject RE: [firebird-support] Database for images
Author Nigel Weeks
Backing up a database of this size would probably be best using a tool like
rsync, that only moves changes between files.

http://rsync.samba.org/



Steps would be:

Shutdown the database on the primary server

Rsync your .fdb file to your backup machine (could take several minutes,
depending on network), which then makes both .fdb files identical

Start your database back up again.



Rsync is available for all platforms, and is completely free.

We use it for all of our firebird synchronizations, even on live databases,
although we use FreeBSD filesystem snapshots, which Linux and Windows are
yet to "invent".

Taking a snapshot of a filesystems allows your database to continue as if
nothing happened, and you can spend as much time as you wish doing a
filesystem copy of the file (eg. Rsync, xcopy, scp, whatever)





Nige.



Nigel Weeks

Tech Support and Systems Developer

Rural Press Tasmania

The Examiner Newspaper

Ph. 03 6336 7234

Mob. 0408 133 738

Email. <mailto:nweeks@...> nweeks@...

_____

From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Aage Johansen
Sent: Monday, 7 May 2007 6:04 AM
To: firebird-support@yahoogroups.com
Subject: [firebird-support] Database for images




I'm contemplating putting all of our images (3+ million, I think)
into a single database. The table will just hold a PK, some
identifying items (<16 bytes), and a blob to hold the images. A
rough estimate gives a size of 350GB, with perhaps an additional 10GB a
year.
A reason for moving from files to a database is to improve access control.
The images are "compressed TIFF" - I'll try to do some additional
compression, but without significant benefit I will keep them as they are.
The size of the images varies: 50-500KB.

Any warnings?
Should I choose a pagesize of 16KB (rather than 8KB or 4KB)? Will it matter?
Currently using Fb/1.5.4

Backup/restore will be fun, of course. But since the images never
change I might put all old images into one database (which will be
totally static), and new images into another one (which will need the
occasional backup). This is really an unneeded complication. Maybe
a better alternative would be to keep the images (coming from a
scanning process), and - if necessary - reload from these.

Advice appreciated.
TiA
Aage J.



__________ NOD32 2229 (20070430) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com



[Non-text portions of this message have been removed]