Comments
Sort by recent activity
Apparently, the compression throws out the storage controller's deduplication algorithms. If all Full backups have the same base data, it will only take (on our SAN side) as much storage space as the delta between the Fulls.
It will show full size on the host side though, but that is what I am being told as to why we are not going to compress them. / comments
Apparently, the compression throws out the storage controller's deduplication algorithms. If all Full backups have the same base data, it will only take (on our SAN side) as much storage space as ...
That's why this is such a tricky deal...We probably will just stick with a single file for the backup, and no compression. The system is 24/7/365, and they want 5 9's always (LOL!!!).
I love what I do! :-D / comments
That's why this is such a tricky deal...We probably will just stick with a single file for the backup, and no compression. The system is 24/7/365, and they want 5 9's always (LOL!!!).
I love what ...
Hi Chris - No - not with Fulls. The only backup type that is getting compression (maximum compression = 4) are the Diffs.
I am not certain to the speed of the platters we are spinning on the internal array for which this db resides (I want to say they are at least 10k, but they could very well be 7200's as well - I doubt they are 15k's, and I am certain that they are not SSD).
I will investigate some of the options of compression and possibly splitting the backup into multiple files, but for now - the time is not a overwhelming concern.
Thanks for sharing your experiences with me though - I know now that I cannot run simultaneous backups of the same db (i.e. fulls/tlog, or diffs/tlog). / comments
Hi Chris - No - not with Fulls. The only backup type that is getting compression (maximum compression = 4) are the Diffs.
I am not certain to the speed of the platters we are spinning on the inter...
ChrisAVWood wrote:
How big are your databases that they take 4 hours to backup and do you include the verify in this time?
The main database is 318gb and growing...The other 3 are about roughly 50gb combined. CHECKSUM and VERIFY are NOT being used for these backups, for the very reason of time constraints. We are able to get around this by doing daily restores of the backups from the night before into our Testing instance.
The main database takes 3hours and 43mins to do a Full backup. The other 3 combined take about an hour. All Fulls and Diffs (as well as TLogs for that matter) run at the same times every day/night. / comments
ChrisAVWood wrote:
How big are your databases that they take 4 hours to backup and do you include the verify in this time?
The main database is 318gb and growing...The other 3 are about roughl...
Again - perfect information! Thank you again Marianne! / comments
Again - perfect information! Thank you again Marianne!
Marianne wrote:
...To do this, upgrade to the v7 trial, then use your existing serial number to activate the license...
Sorry to sound like such a dolt here, but where exactly can I find the serial number in the software? I know - this should be documented, but I am a contract consultant, and have been asked to try and upgrade our version 6 installs (to see if our support agreement is still active). If not - we will pay for the upgrade, but no one seems to know where the numbers are at (outside of the possibility that you can tell me where to find them in the SQL Backup 6 app).
Can I find it in the app somewhere? / comments
Marianne wrote:
...To do this, upgrade to the v7 trial, then use your existing serial number to activate the license...
Sorry to sound like such a dolt here, but where exactly can I find the s...
Thank you Marianne! That is perfect information, and I do appreciate it. / comments
Thank you Marianne! That is perfect information, and I do appreciate it.
Hi Eddie - no, I did not run a full, but made the change just before the Full was scheduled to kick off (missed it by a few hours). As you noted - even the Diffs made no different for the TLog until the Full ran, but I am happy to report that all my backups are running very well now.
I have posted a new thread to see about running the TLogs while the Fulls and Diffs are running though...Is that something that should not be done? Or does SQL Backup know what to do to simultaneously perform each backup type in parallel to one another?
Thank you again! / comments
Hi Eddie - no, I did not run a full, but made the change just before the Full was scheduled to kick off (missed it by a few hours). As you noted - even the Diffs made no different for the TLog unt...
eddie davis wrote:
Unfortunately you cannot take simultaneous Full, Diff and TLog backups of the same database, using SQL Backup...
So - should I delete the ones that ran at the same time as the Fulls and Diffs in the past? That of my TLog backups?
They all ran without error (simultaneously), but are you saying that they are corrupt and no good? / comments
eddie davis wrote:
Unfortunately you cannot take simultaneous Full, Diff and TLog backups of the same database, using SQL Backup...
So - should I delete the ones that ran at the same time as t...
Nevermind - found the problem. I went back into Backup 7, and saw that the Transaction Log backup wasn't even available to those other 3 databases, and it clicked - they must be in simple recovery mode.
Sure enough - that is what it was. Switched them over to Full Recovery, and they should be ok come 10pm tonight when our next Differential backup runs. / comments
Nevermind - found the problem. I went back into Backup 7, and saw that the Transaction Log backup wasn't even available to those other 3 databases, and it clicked - they must be in simple recovery...