Logs in SQL servers are used to keep recent changes, since they are usually smaller than the datafiles and writing to them takes less time to the datafile itself. By default, SQL Server will keep adding data to the log files until they are backed up. Once the log files are backed up, they will be emptied BUT NOT SHRINKED :) You can turn on the auto shrink on though, however bare in mind that this will cause I/O problems.

Shrinking of a log file is done for TEMPORARY solution. Don't forget that after the logfile is shrunken, it will most probably grow back. Therefore, do that only in special cases and as temporary solution. Permanent solution for that, will be to add more disk space.

There are 2 types of shrinking, with or without truncate as follows:

The first, truncate only, might not reduce the space on the file system:

USE [victores_eur]
GO
DBCC SHRINKFILE (N'victores_eur_log_01' , 0, TRUNCATEONLY)
GO

In such case, just remove the TRUNCATEONLY option and SQL server should be able to release space much as it can:

USE [victores_eur]
GO
DBCC SHRINKFILE (N'victores_eur_log_01' , 0)
GO

You can also shrink to a specific amount, let's say 65 GBs as follows:

USE [victores_eur]
GO
DBCC SHRINKFILE (N'victores_log_03' , 65536)
GO

This command will move the data as well.

You can check the log file content and see if the records are empty or not:

USE [victores_eur]
GO
DBCC LOGINFO;
GO

This should show you information as follows(I edited some fields so they can fit):

RcUntId Field   FileSize Offset FSeqNo Status Parity  Create LSN
0	2	253952	8192	258219	0	64	0
0	2	253952	262144	258220	0	64	0
0	2	253952	516096	258221	2	64	0
0	2	278528	770048	258218	0	128	0
0	2	16777216	1048576	257121	0	128	103151000000013600188
0	2	16777216	17825792	257122	0	128	175680000002100300356

Here you can see if any virtual logs are in use by seeing if the status is 2 (in use), or 0 (free). When shrinking files, empty virtual logs are physically removed starting at the end of the file until it hits the first used status. This is why shrinking a transaction log file sometimes shrinks it part way, but does remove all free virtual logs which you may expect.

If you notice a status 2's that occur after 0's, this is blocking the shrink from fully shrinking the file. To get around this do another transaction log backup, and immediately run these commands, supplying the file_id found above, and the size you would like your log file to be reduced to.

You can extend a log file, in case it was shrunk too much as follows:

USE [master]
GO
ALTER DATABASE [victores_eur] MODIFY FILE ( NAME = N'victores_log_03', SIZE = 67108864KB )
GO

https://stackoverflow.com/questions/7193445/dbcc-shrinkfile-on-log-file-not-reducing-size-even-after-backup-log-to-disk