database size vs size in backup
-
Hi,
Lately I have been wondering about this. Im storing attachments in my database (on a small server with only about 10 users) my database is 25G but when I count the sizes of the resulting kopano backups of all users and public folders Im getting only 12G. Are attachments stored uncompressed base64 in the database or where is this huge difference coming from? I have allready ran optimize tables on properties, tproperties and blobs to try to eliminate space and I have deleted all soft deletes to no avail.
Any info about this topic is appreciated.
regards,
-
Yes, I don’t think that attachments stored in the database are compressed.
In any case: regardless of how less users you have in your system I would always recommend to store attachments on disk.
-
Hi Felix,
thanks for you answer. My main reason to keep files in DB : my db server has a replicating slave off site. I dont like the need for 2 different syncing mechanisms for 1 dataset, especially when one is almost synchronous and the other one isn’t.
-
For attachments, you also do not really need synchronous replication.
-
@tbone said in database size vs size in backup:
thanks for you answer. My main reason to keep files in DB : my db server has a replicating slave off site. I dont like the need for 2 different syncing mechanisms for 1 dataset, especially when one is almost synchronous and the other one isn’t.
Since storing databases outside of database is recommended… The off site slave is used for instant backup purposes and loosing less information possible, right? Maybe you should have a look for either unison with inotify or some replicating file system (like i.e. glusterfs, drbd) - but replicating / mirror file system could be a performance killer and should be setup with care.
Regarding your initial question - just my guess… Kopano is storing some information in database duplicated and in an performance oriented way (i.e. imap props for gateway). Additionally there are indexes. All things that usually will be dropped by a backup since being recreated by a later on restore…
Andreas
