[Help] Someone Help me with the solution to the LOG file too big?

[Only registered and activated users can see links. Click Here To Register...]

Disable logs xD

Or if you still want them just disable a specific type of Log like SMC/Item/Char.

Just simply stop backupping every day. Each backup will accumulate to the total size of the file. Make a fresh independent new backup (in another folder) and change the resource path of the live backups.

Quote:

Originally Posted by blapanda Just simply stop backupping every day. Each backup will accumulate to the total size of the file. Make a fresh independent new backup (in another folder) and change the resource path of the live backups.

my backup is via FTP
one by one hour
don't save in HD

Quote:

Originally Posted by xxnukertube my backup is via FTP one by one hour don't save in HD

(All locally, where the main SQL Server instance runs at and/or is bound to.)

The "*.bak" file just contains the current database. Everything which is currently running, has been set up. Like for example disabled medusa spawn, enabled degree 15 items, and so on. Creating a backup will save them to the *.mdf/*.ldf containers. Lets call that "backup01".

Those "*.mdf/*.ldf" files contain the changes after all.
If you now for example change the service of the medusa spawn as enabled and disabling all degree 15 items and create a backup, it will automatically accumulate the changes like a new page in a book. It will be called "backup02" and will be placed next to backup01.

Backuping with SQL will never overwrite pre-existing server information and data, unless you specifically change the options for it.

So, everytime you change something and backup stuff, it will add it to the containers.

First backup will be 70mb, second one another 70mb, which sums up to 140mb. The next one 70mb (or even more, if you added loads new stuff to it), which will result into 210mb, aaand so on.
You get the point.

TL;DR
*.bak files contain the current data which has been backuped.
*.mdf/*.ldf does contain every single backup you did in the past till now.

Source: Own experience. Try to change the settings, like adding a deadline for the backup cluster. Deleting backup data which are older than 14 days or such. This will limit your total file size.

Quote:

Originally Posted by blapanda (All locally, where the main SQL Server instance runs at and/or is bound to.) The "*.bak" file just contains the current database. Everything which is currently running, has been set up. Like for example disabled medusa spawn, enabled degree 15 items, and so on. Creating a backup will save them to the *.mdf/*.ldf containers. Lets call that "backup01". Those "*.mdf/*.ldf" files contain the changes after all. If you now for example change the service of the medusa spawn as enabled and disabling all degree 15 items and create a backup, it will automatically accumulate the changes like a new page in a book. It will be called "backup02" and will be placed next to backup01. Backuping with SQL will never overwrite pre-existing server information and data, unless you specifically change the options for it. So, everytime you change something and backup stuff, it will add it to the containers. First backup will be 70mb, second one another 70mb, which sums up to 140mb. The next one 70mb (or even more, if you added loads new stuff to it), which will result into 210mb, aaand so on. You get the point. TL;DR *.bak files contain the current data which has been backuped. *.mdf/*.ldf does contain every single backup you did in the past till now. Source: Own experience. Try to change the settings, like adding a deadline for the backup cluster. Deleting backup data which are older than 14 days or such. This will limit your total file size.

How i can clean the Backup into .mdf / .ldf file ?

Quote:

Originally Posted by xxnukertube How i can clean the Backup into .mdf / .ldf file ?

Just by entering a new path for the backup process. Check also the other tabs reallocating the new mdf and ldf paths and consider adding a deadline for old cached backup data.