I'm assuming that an initial FULL BACKUP is required if I am taking
FILEGROUP backups and would like this confirmed.
Answer
No, a initial FULL BACKUP is not required in order to take FILEGROUP backups.
The documentation states that
Under the full recovery model, a complete set of full file backups,
together with enough log backups to span all the file backups, is the
equivalent of a full database backup.
It also says
Restoring a database using just file and log backups can be complex.
Therefore, if it is possible, it is a best practice to perform a full
database backup and start the log backups before the first file
backup.
Lab Test
Here's an example of a scenario where a FILEGROUP backup and LOG backups (without a FULL backup) are enough to restore a database file:
CREATE DATABASE MyDB
ON PRIMARY
( NAME = N'MyDB', FILENAME = N'D:\MyDB.mdf'),
FILEGROUP [FILEGROUP_1]
( NAME = N'File_1', FILENAME = N'D:\File_1.ndf')
LOG ON
( NAME = N'MyDB_log', FILENAME = N'D:\MyDB_log.ldf');
ALTER DATABASE [MyDB] SET RECOVERY FULL;
Now that we have a database, let's start the changes.
USE MyDB;
CREATE TABLE table_File_1(numbers int NOT NULL)
ON FILEGROUP_1;
INSERT INTO table_File_1(numbers)
VALUES (1), (2), (3);
BACKUP DATABASE MyDB
FILEGROUP = 'FILEGROUP_1'
TO DISK = 'D:\backups\MyDB_FILEGROUP_1.bck';
BACKUP LOG MyDB
TO DISK = 'D:\backups\MyDB_LOG_1.trn';
DROP TABLE table_File_1;
USE master;
RESTORE DATABASE MyDB
FILEGROUP = 'FILEGROUP_1'
FROM DISK = 'D:\backups\MyDB_FILEGROUP_1.bck'
WITH RECOVERY;
RESTORE LOG MyDB
FROM DISK = 'D:\backups\MyDB_LOG_1.trn'
WITH RECOVERY;
Notice that the restore isn't complete at this point for SQL Server requires that transaction logs are enough to bring the LSN up to the point where the database is (in this simulation only one file is being restored while the database was still online and the other files are being modified) and after restoring this backup you get the following message:

If you query sys.master_files
, you'll see that File_1 is not online yet.
SELECT file_id, name, state_desc
FROM sys.master_files
WHERE database_id = DB_ID('MyDB');
Here's the result of that query:

It means more log backups must be restored to bring this file online in a consistent state. In this scenario we can take a new log backup and restore it right after it was taken.
BACKUP LOG MyDB
TO DISK = 'D:\backups\MyDB_LOG_2.trn';
RESTORE LOG MyDB
FROM DISK = 'D:\backups\MyDB_LOG_2.trn'
WITH RECOVERY;
Now you're done. After restoring MyDB_LOG_2.trn
you get this message:

And querying sys.master_files
you can see that File_1 is now online

Remarks
- As the documentation stated and the example showed it's possible to
have a backup strategy with
FILEGROUP
and LOG BACKUPS
without a FULL BACKUP
;
- Notice that restoring these backups didn't bring back the dropped
table and the reason is that our backup plan wasn't enough to restore
all the files in a manner that I could stop the restoring at the point the table still existed (so be careful when planning your
backup strategy).