You will need to set up a separate backup device for the FULL and the DIFF. When you create the Backup Device it is a single file. You can't save a FULL and a DIFF in the same Backup Device.
If you are trying to restore the database over an existing database and want to replace the data you will need to use the WITH REPLACE option in the restore. More information can be found here: http://msdn.microsoft.com/en-us/library/ms186858.aspx
REPLACE should be used rarely and only after careful consideration.
Restore normally prevents accidentally overwriting a database with a
different database. If the database specified in a RESTORE statement
already exists on the current server and the specified database family
GUID differs from the database family GUID recorded in the backup set,
the database is not restored. This is an important safeguard.
The REPLACE option overrides several important safety checks that
restore normally performs. The overridden checks are as follows:
Restoring over an existing database with a backup taken of another
database.
With the REPLACE option, restore allows you to overwrite an existing
database with whatever database is in the backup set, even if the
specified database name differs from the database name recorded in the
backup set. This can result in accidentally overwriting a database by
a different database.
Restoring over a database using the full or bulk-logged recovery model
where a tail-log backup has not been taken and the STOPAT option is
not used.
With the REPLACE option, you can lose committed work, because the log
written most recently has not been backed up.
Overwriting existing files.
For example, a mistake could allow overwriting files of the wrong
type, such as .xls files, or that are being used by another database
that is not online. Arbitrary data loss is possible if existing files
are overwritten, although the restored database is complete.
Best Answer
Each differential backup is composed of the pages that have changed since the last full backup. So if you take a full backup on Sunday, then diffs on Monday, Tuesday, etc. then restoring the database will only require Sunday's full backup, followed by the most recent day's differential.
However, by overwriting your diffs each day, you are losing the ability to restore to a previous point in time. Example: Let's assume you take backups at 1 AM daily. On Thursday afternoon, you discover that data got corrupted on Wednesday and you need to get back to the last known good state. You can't, because the differential backup at 1 AM Wednesday (which would be clean) has been overwritten by the Thursday 1 AM backup which is corrupt.
So to answer your question, it is safe if and only if you assume that you will never have to revert to anything but the most recent backup, and that backup is always correct and corruption-free. I am not staking my job on that assumption.
I would not endorse the scheme you're proposing. Storage is relatively cheap - how much is the data worth to the company? Move the backups off to another, larger, cheaper datastore on a regular basis if space is at a premium, so that you can comply with any data retention policies, regulations or laws as needed.