While the other answers showed that the amount of data is not so big to fill a 2TB disk, you should consider access speeds to that data as well. If you use traditional computer hard disks and not SSDs, they can do only about 100 random accesses per second (perhaps a little less for 7200 RPM desktop disks and a little more for 10000-15000 RPM enterprise disks).
Typical relational databases store the information on a flat file, meaning that if there are 1000 active users, you will have the following structure: user0data0 user1data0 user2data0 ... user999data0 user0data1 user1data1 user2data1 ... user999data1 ... meaning that fetching many data points belonging to one user means one random access per data point.
Now, if your entire dataset doesn't fit into memory (typical servers have 32-64 GB memory, and you will fill that amount in 1-2 years), if you want e.g. to obtain the last day's data points for a random user, it takes 86 400 random accesses, which is 864 seconds or over 14 minutes. Do you have the possibility to wait for 14 minutes for the last day's data? Probably not.
What if you store a given user's data points inside a single document such as a file? The information of files is typically stored consecutively in disk (although some newer file systems such as ZFS and btrfs break this assumption, but let's assume you are using traditional file system such as ext2, ext3 or ext4). Now to fetch 86400 data points, it requires one random disk seek and sequential scan of 86400 data points. At 8 bytes per data point, it's 0.66 megabytes taking about 7 milliseconds to read (assuming you read only the data points of interest and not the whole document). This added to the seek of 10 milliseconds is 17 milliseconds. If you read the whole document for a year, it's 2.6 seconds sequential scan and 10 milliseconds random seek, which may be a problem.
So, I would consider breaking the documents to smaller pieces: one document per day per user.
So, as a summary, SQL databases are not the technology to use to store the location data. Your idea is good, but might require refinement (breaking the large file into smaller per-day pieces).
Whatever you do, please implement tests to populate the database with data, in the same order where the data would arrive in a real system. Then do random queries to the data, e.g. to obtain the path of a random user in a random day, and measure the performance of those queries.
Edit: There may be some database-dependent technologies that could allow reducing the overhead of random accesses. For example, recent versions of PostgreSQL support index only scans. This means that if you create an index that contains all columns you access in the query, the query will be satisfied only from the index. MySQL InnoDB supports clustered indexes, where the data is stored in the index instead of a flat file. However, by using these technologies, you are making your program's performance depend on internal implementation details of the database. Do you want that? If you are certain that you will not switch to another database that lacks these features, you could with these features obtain acceptable performance. However, if you want to make your program database-independent, storing the location data elsewhere is a good idea.