In 2015, EmpireCLS had a 1 Terabyte database that was difficult to manage. A restore of this database would take several hours which would not be suitable as a disaster recovery option.
We analyzed the database and usage and were able to use a custom partitioning scheme to keep rolling windows of table and index data on a monthly basis. We were able to then roll off the windows after a certain time period.
Daily backups would only occur on the active filegroups and inactive filegroups would be treated as read-only. The restore of the last active filegroup would then take minutes because it was extremely small.
Another goal of this partitioning was the need to move filegroups around the network easier and being able to restore individual filegroups without affecting disk performance. It was determined that restoring the terabyte backup would not only take a long time but would saturate the SAN that EmpireCLS was using. By only needing to restore 10GB backups these issues were removed.
An more technical explanation can be found here…SQL Server Custom Partitioning