We have very good experience with using shadows as a much faster backup alternative.
Up to fb254 we can do some changes on RDB$FILES to avoid the file delete, that is done
automaticaly when using DROP SHADOW.

It would be a very good feature for Firebird 3, when we can use the DROP SHADOW command with an additional
new option, that does not drop the shadow file from the filesystem.

We use this way especially in combination with RAM Disk to create and drop a shadow. Since the shadow file can
be used as a database directly, we save a lot of time compared to a full backup/restore process. Our
current way with changes in RDB$FILES will not work in FB3, but we and our customers would really like to have
such a new option to be able to use the same technology on fb3.

And yes, we know, that a shadow does no transaction reset, garbage collection etc., but here are some numbers i
showed a customer yesterday on my laptop (all operations were done on a 240 GB enterprise SSD in a i7 Laptop
with 8GB RAM, Customer database was 1.6 GB, almost no blobs, but a lot of records and a lot of indices)

Backup using gbak fb254 win64: 65 seconds
Restore using gbak fb254 win64: 410 seconds

overall around 8 minutes

and now using a script in ibexpert using a ramdisk and a shadow

-create shadow
-commit;
-update rdb$files
-commit
-drop Shadow
-commit

overall around 8 seconds!


Really, the whole script used 8 seconds! The customer was extremly impressed, especially since they
control very large machines using their software and firebird

We use the same way with database up to 10 GB and there we have a typical time of 30 seconds

This makes it possible for the customer to start the shadow based backup/restore replacement job every 30
minutes, since it only uses 30 seconds of high load. After creating the shadow on the ramdisk and dropping it,
it is copied to their backup server.

I think such an additional option for drop shadow statement should not be a bug deal for the core developers