Daarom waarschuw ik hem ook

. Je kan er ZO vreselijk mee de mist in gaan.
Als je schijf vol loopt door logs dan klopt inderdaad je backup niet. SQL Server moet door hebben dat zowel de transaction logs als de database zijn gebackupt voordat het deze gaat overschrijven. Een Full backup backupt alleen de database files, NIET de transaction logs. SQL Server zal deze daarom ook niet gaan overschrijven. Je moet dus niet alleen een Full backup maken, maar ook een Transaction Log backup.
Wij maken van de meeste databases iedere dag een full backup en ieder uur een transaction log backup.
Zelf shrinken om schijfruimte terug te krijgen kan, maar het wordt afgeraden dat routinematig te doen. Als je backups goed lopen, dan is de ruimte die de logs innemen de ruimte die het nodig heeft tussen de backups door. Shrinken doe je eigenlijk alleen als er iets mis is gegaan met de backup, of je hebt iets als een eenmalige batch-job (zoals een migratie) gedaan waardoor de logs veel groter zijn dan normaal.
Als je geen point-in-time restores hoeft te doen / wil doen van je database en je komt schijfruimte tekort dan kun je ook overwegen het recovery model op simple te zetten; dan staan de in de transaction logs alleen de actieve transacties die nog een rollback kunnen krijgen, maar geen historie. Je kunt dan dus je database alleen maar restoren naar het punt waarop je de database-backup hebt gemaakt.
Het gaat volgens mij om Exchange. Zelfde database structuur maar een ander beestje omdat je niet rechstreeks SQL commando's kan vuren. Als je met SQL een uitweg moet hebben terwijl je vast zit, en de transaction logs groeien de pan uit, dan het ding op simple zetten, daarna weer op full en dan meteen een backup maken in de hoop dat je niet meer terug hoeft.
Voor Exchange moet je in ieder geval zorgen dat je logchain in orde is. Iets wat je kapot maakt door met Windows Backup een
full backup te trekken terwijl je hetzelfde doet met Veeam.
2 commando's kan je proberen om te checken :
Eseutil /MH database_name.edb
Eseutil /ML file_name.log
LET OP

Je moet de database unmounten. Dat wil zeggen, geen mail meer zolang je bezig bent.
Als je consistentie problemen aantreft ben je aan de beurt. Advies is dan om niet zelf te gaat proberen. Dat had laatst iemand hier ook gedaan en die ging van de regen in de drup. Heel snel.
Who's General Failure and why is he reading my harddrive? - Projectmanager : a person who thinks nine women can make one baby in one month