A FastCompression backup has the form: <DatabaseName>.litespeed.<index>.bkp
The index is a 1 to 4 part naming index of the form f#[.d#][.s#][.m#]
f: Full backup id of backup taken by the Fast Compression (FC)
Starts at 0 and incrementing
d: Differential id of backup taken Fast Compression
Starts at 0 and incrementing for *each* full backup
Only exists if this is a differential
s: Stripe id of b the backup file
Only exists if this is a multi-stripe backp
m: Mirror id of backup
Only exists if this a mirrored backup (not a primary)
So:
Foo.litespeed.f10.bkp: Eleventh full backup produced by FC (single-file, not mirrored)
And
Foo.litespeed.f6.d1.s3.m2: Fourth stripe file of third mirror of second differential applicable to seventh full backup
There is one degenerate case where FastCompression has been instructed to create a backup and it produces a differential (non-escalation or prohibited from creating a full on that day), but someone has gone and produced their own full backup… By nature of the way SQL Server works. This diff cannot be applicable to the last full backup taken by FC and thus it is not tied to a FC-Full-backup-id…
It is tied to the user full backup, in which case there can bee seen the odd syntax like: AdventureWorks.litespeed.f(AdventureWorks.bak 2013-05-01 10-07-06).d0.m0.bkp
Therefore, this is a FC differential backup (first mirror) of the AdventureWorks database that is applicable to a backup named AdventureWorks.bak taken on 5/1/2013 at 10:07:06 AM
