Error message: The transaction log for database 'BoringBase' is full due to 'LOG_BACKUP'
This happens when BoringBase is in the FULL recovery model with no transaction log backups running, so the log grows until it fills up. The fix switches it to SIMPLE recovery, which lets SQL Server reuse log space automatically.
Before you start: If your backup policy requires point-in-time restore for BoringBase (scheduled transaction log backups), don't use this procedure — contact us instead.
You'll need: SQL Server Management Studio (SSMS) and sysadmin or db_owner rights. Takes about 5 minutes; no restart required.
Step 1 — Connect to the SQL Server instance
- Open SQL Server Management Studio.
- In the Connect to Server dialog, enter the server name of the SQL Server instance that hosts BoringBase (often the same machine running your Milestone/VMS server, e.g.
SERVERNAMEorSERVERNAME\SQLEXPRESS). - Choose your authentication method (Windows Authentication is typical) and click Connect.
Step 2 — Open a new query window
- In Object Explorer (left panel), confirm you can see the BoringBase database under Databases.
- Click New Query in the toolbar.
Step 3 — Switch BoringBase to SIMPLE recovery
Paste and run the following (press F5 or click Execute):
ALTER DATABASE [BoringBase] SET RECOVERY SIMPLE;
You should see Commands completed successfully. in the Messages tab.
Step 4 — Find the log file's name and current size
The log file has likely grown very large. To shrink it, first find its logical name:
USE [BoringBase]; SELECT name, type_desc, size * 8 / 1024 AS size_mb FROM sys.database_files;
In the results, note the name of the row where type_desc is LOG (commonly BoringBase_log), and note its size in MB.
Step 5 — Shrink the log file
Run the following, replacing BoringBase_log with the logical name from Step 4 if it differs:
USE [BoringBase]; DBCC SHRINKFILE (N'BoringBase_log', 1024);
This shrinks the log file to roughly 1 GB, which is plenty of working space. When it completes, you'll see a results row showing the new size.
Step 6 — Verify
Run this to confirm the recovery model and new log size:
SELECT name, recovery_model_desc FROM sys.databases WHERE name = 'BoringBase';
The recovery_model_desc column should now read SIMPLE.
Step 7 — Restart the Boring services and IIS app pools
Finally, restart the Boring Toolbox services and IIS app pools so everything reconnects to the database cleanly.
Restart the Windows services:
- On the server running Boring Toolbox, press Win + R, type
services.msc, and press Enter. - Locate each of the following services, right-click it, and choose Restart:
- Boring Live Monitoring
- Boring Milestone Proxy
- Boring Service Host
Recycle the IIS app pools:
- Press Win + R, type
inetmgr, and press Enter to open IIS Manager. - In the left panel, expand the server node and click Application Pools.
- Right-click each of the following and choose Recycle:
- BoringLabService AppPool
- BoringToolboxWeb AppPool
Prefer the command line? Run this in an elevated PowerShell window instead:
Once the services and app pools are back up, log in to Boring Toolbox and confirm everything is working normally.
FAQ
Will this delete any of my data? No. Changing the recovery model and shrinking the log file does not touch any data in the database — it only changes how SQL Server manages its transaction log.
Will this happen again? No. Under the SIMPLE recovery model, SQL Server automatically reuses log space, so the log will no longer grow unbounded.
Does this affect my backups? Full database backups continue to work exactly as before. The only capability you lose is point-in-time restore via transaction log backups — which wasn't functioning anyway if you were seeing this error.
Still stuck? If you see a permissions error, run SSMS as a user with sysadmin rights on the SQL instance. If the error persists after these steps, check that the disk hosting the log file isn't completely out of free space, then reach out to our support team with a screenshot and we'll take a look.
Comments
0 comments
Please sign in to leave a comment.