April 27, 2025 at 12:23 pm
Hi Guys,
I'm not sure if this is possible or not, but let me explain my situation.
I have a scenario where I need to create a job that takes a backup(With Compression), keeps recent backups, and deletes older ones based on the date.
The problem is, my database is quite large, and I don't have enough disk space.
As a solution, I tried to omit some log tables and other tables that I don't need, but I couldn't find an option to do this while creating a .bak file.
Another idea I had was to create a temporary database with only the required tables, or delete the unwanted tables before backup, but I don't think that's the right way to do it.
Is there any way to omit specific tables while taking a backup?
April 27, 2025 at 1:39 pm
This was removed by the editor as SPAM
April 27, 2025 at 10:40 pm
Looks like you would have to put all the items you want backed up into one or more filegroups (so that you can leave out the ones you do not want backed up). Then you'd just back up the filegroups instead of the entire database. See: https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/back-up-files-and-filegroups-sql-server?view=sql-server-ver16
April 28, 2025 at 7:18 am
The OP needs to ask what restores they will need and under what circumstances. Backups can then be planned to align with the restore strategy. Then the restores need to be regularly tested. I suspect the OP needs more disk space; not filegroup backups.
April 28, 2025 at 1:07 pm
Backup is an all or nothing thing. As was stated, you can make it so you backup individual filegroups, but you'll get everything in the file group, just as a full backup gets you everything in the database, or a log backup gets you everything in the log. There isn't a way to exclude much of anything.
But backups aren't important. Restores are important. If you do rearrange your storage so some tables are in different file groups, can you effectively restore the database? That's the key question. If not, you're in the same place you are now. You have to be able to restore your databases. Anyone can take a backup. It's whether or not you can restore that truly matters.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 28, 2025 at 5:33 pm
Thanks for the reply, mate.
I try to implement that and get back to you.
April 28, 2025 at 5:41 pm
Thanks for the response,
You're right. restore is what really matters. Even if I omit some tables, it doesn't significantly reduce the space. So now, I feel it's better to stick with the default method rather than using third-party tools and their approaches.
I think I'll focus on increasing my disk space instead of trying to reduce tables
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply