Do you know how long each database backup is taking? Has the time increased for a single backup or all of them?
Apart from the slowdown issue, with 3.5TB of data, it's time to stop using maintenance plans and move to a custom scripted backup solution.
There is a commonly used solution here (I have not used it personally but it's widely used elsewhere) http://ola.hallengren.com/
That will at least give you some better logging. I'm not sure of your level of experience, but it sounds like you'll need to research more about backup performance tuning. What is the best performance you can achieve by backing up to a NUL device? There are switches like BLOCKSIZE and BUFFERCOUNTS which can make a huge difference in backup times and throughput. Actually what throughput are you achieving to the SAN in MB/s or IOPS?
You'll need to investigate the wait activity occuring at the time of the backup too. You can use this code, but remember you will lose all the wait statistics when running the DBCC clear.
-- Clear Wait Stats
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR);
-- Isolate top waits for server instance since last restart or statistics clear
WITH Waits AS
(SELECT wait_type, wait_time_ms / 1000. AS wait_time_s,
100. * wait_time_ms / SUM(wait_time_ms) OVER() AS pct,
ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS rn
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK'
,'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP'))
CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
INNER JOIN Waits AS W2
ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 99; -- percentage threshold