Hi Tim,

Just as a thought - when doing Backups with DBISam it currently backups
everything (data, index and blobs).

Just wondering what the possibilities might be of creating a new DBISam
backup that only backups metadata of the indexes, so when it's restored
it recreates the index file.

Looking at some of my tables, the index files can be significant in
size, and this would reduce the backup file sizes substantially.

Thoughts?

Cheers

Adam.

Adam,

The main benefit of the current backup/restore in my view is that it's very fast - for example i'm able to backup a 2GB database in less than 3 minutes and restore it even faster (little over a minute).  
In comparison rebuilding an index on one of the larger tables (650MB of data and 900MB of index) takes comparatively forever (20+ minutes is norm).

Storage is cheap - i've seen 2TB drives for approx $100 lately - so i definitely want the current backup method retained as default since nothing beats quick restore when troubleshooting or recovering a database.

If Tim does decide to add an option to backup "data only" then it should be a separate option (that is off by default).

My $0.02
Raul

Hi Raul,

You raise a good point, and I would agree with you.

In my particular instance we are doing backups between sites and can be
transferring 400mb+ per night across the internet. This is only going to
grow for us, so I'm trying to find some sort of plausable solution to this.

I guess one option may be to copy the tables to a second directory,
remove all the indexes and then do a backup and create another procedure
to re-add the indexes when needed.

Cheers

Adam.

Adam,

The Internet is a challenge and every byte less can help. However, assuming your data will grow over time you'll be back to same backup size even with "data only backup" soon.

We had a similar problem except we needed to copy data a lot more often than nightly so we built replication into our app that essentially exports the deltas (rows modified) from source system, sends them over to other side and re-inserts into destination tables. The changes are tracked by the update/insert and delete triggers in our case. You do need a proper primary keys in your tables or create one at least for this process.

It works quite well over Internet since deltas are relatively small.

Raul

Hi Raul,

Thanks for your idea. In this particular instance it's used for backups
rather than replication. Yes - over time the data will grow but bytes is
$'s and if we can get the backups down to roughly half the size then
effectively we'll be halving the cost regardless of how big the backups
get.

Just a thought.

Cheers

Adam.