Backup van databases

[Sylvester]

Even verduidelijken : op een mini PC'tje met Windows 10 home draait een monitoring programma voor PV installaties.
Voor de geïnteresseerden :
http://www.solarview.info/solarview_windows.aspx
Een voorbeeldsite :
http://solarlogger.dyndns.tv

Ik weet niet veel van de achtergrond van deze software. De database is een .db file die per dag groter  wordt. Er worden om de 5 minuten gegevens in geschreven zolang de zonne-installatie draait , dus zolang er daglicht is. 's Nachts wordt er niets geregistreerd in die .db file.

Nu ben ik onlangs overgeschakeld van een oude Windows XP naar een nieuwe mini-PC met Windows 10 home.
Op de oude Windows XP draaide Cloud Station Backup. Deze maakt dus onmiddellijk een backup van zodra een file wordt aangepast.
In het geval van die databas dus om de 5 minuten.

Ik heb eens gelezen dat het maken van een backup van een database soms kritiek is. Als je een kopie maakt op het moment dat die nog actief is, kan de database niet volledig zijn, of zoiets....

Nu heb ik ook gemerkt dat een paar backups ( en ik heb maar enkele backups) van die .db file niet in orde zijn. Alle files omheen die database zijn in orde maar de .db zelf niet.  Bij sommige backups is die gewoon leeg, terwijl de grootte (250 MB op dit moment) toch klopt.
Een andere backup was corrupt, foute data.
Gelukkig had ik een paar backups van een maand geleden , die ik toen nog met Freefilesync en handmatig had gemaakt op een moment dat de software niet actief was, 's avonds dus.

Wat is jullie ervaring hiermee. Wie weet hierover iets meer?
Zou het kunnen dat die .db files niet correct gekopieerd worden met Cloud Station Backup ?

[Hofstede]

Normaalgesproken kun je database files inderdaad niet kopieren terwijl de database geopend is. Je moet de database sluiten  voordat je hem kopieert.
Er zijn wel speciale backupprogramma's die specfieke types database types kunnen kopieren terwijl ze actief zijn, maar lijkt me niet het geval voor Cloud Station backup.

Wat je kunt doen:
Zelf om de zoveel tijd een export maken van de database en deze exportfile backuppen met Cloud Station backup.

[Ben(V)]

Een database file kun je nooit zo maar een kopie van maken, dus ook niet met Cloud Station Backup.
Dat kan alleen maar als je zeker weet dat er niets gewijzigd wordt op dat moment en dat de database cache geflushed is (e.g. de data is committed).

Je zult eerst uit moeten zoeken welke database het is maar gezien het feit dat het een enkel bestand is met de extensie .db vermoed ik dat het een SQLite database is.
Dit kun je controleren door het bestand te proberen te openen met "DB browser for SQLite", die kun je hier vinden:
http://sqlitebrowser.org/

Als je daarna weet dat het een SQLite database kun je met de commandline tools voor SQLite een backup maken
Zie;
https://www.sqlite.org/cli.html

[Sylvester]

Ha, die krijg ik niet open, is beveiligd met een paswoord.
Ik kan toch niet elke dag manueel met één of andere command line tool een backup maken?

's Nachts is er sowieso geen activiteit, ik ben zo goed als zeker dat het dan kan. Allé, ik meen me toch te herinneren dat de man in kwestie dat ooit eens heeft gezegd.
Maar Cloud Station Backup kan dat niet, neem ik aan?

[Ben(V)]

Hyperbackup zou ik aanraden en dan 's nachts een backup draaien.

Maar aangezien die database dedicated bij die applicatie hoort kan het zomaar zijn dat die applicatie die database gelocked houd en dan kun je helemaal geen betrouwbare backup maken.

Afhankelijk hoe goed de programmeur is kan er van alles mis gaan.
Het zou niet de eerste keer zijn dat een ontwikkelaar het laatste record gelocked houd tot hij aan een volgend record begint.
Dan is het laatst geschreven record altijd gelocked en is elke backup die met het hele bestand werk onbetrouwbaar zolang die applicatie draait.

[Robert Koopman]

Met Hyperbackup kan het volgens mij wel.
Ok, het terugzetten heb ik nog niet getest maar met het vorige backup programma van Synology ging het zeker.
Je maakt een backup van MariaDB, ja de databases zijn dan even niet bruikbaar, maar je restored het zo.
Getest op een andere NAS en alle databases stonden er keurig op.
Ik maak in de nachtelijke uren deze backup, websites worden dan amper/niet gebruikt.

[Sylvester]

Die CloudStation Backup is mooi, voor als je werkt met veel 'normale' documenten.
Ik laat die CloudStation in elk geval draaien, je weet maar nooit waarvoor die backup kan dienen.

Volgens mij kan Hyper Backup geen backup van die PC maken. Ik weet niet waar jullie dit vandaan halen? Of misschien heb ik het mis?

[proxydude]

Ik heb in het verleden dit gebruikt http://www.mysqldumper.net/faq/ Het is een php script. Meschien is dit wat je zoekt? Met mysql toen getest weet alleen niet of met sqlite werkt.

[Sylvester]

Ik had het eigenlijk over meerdere databases voor meerdere toepassingen.
Thuis voor mijn eigen database is er ondertussen geen probleem. Ik heb ondertussen een backup 's nachts draaien met Freefilesync.
Werkt prima en alles geraakt door de backup.

Op de andere plaats draaien drie (soorten) databases voor 3 toepassingen. Voor twee hiervan geen probleem. Deze wordt netjes in de backup gezet.
Voor de derde is er wel een probleem. Ik zie dat die een MSSQL database is en dat er continu een aantal documenten 'open' staan. Verder ken ik niks van MSSQL maar ik zie wel dat sommige documenten niet door de backup kunnen. Freefilesync meldt bij een aantal documenten uit de MSSQL map dat het document in gebruik is.
Ook als ik de betreffende documenten met de hand probeer te kopiëren gaat het niet.

Ik heb ook nog steeds Cloud Station Backup simultaan draaien. Deze gaat gewoon door en slaat de niet kopiëerbare documenten over.

Nu vind ik in de log file van Cloud Station Backup géén duidelijke error die dit probleem omschrijft.
Het enige dat ik zie is een regel die een aantal keren verschijnt  : 'System heeft het bestand sync.ffs_lock' verwijderd' . Dit is het enige 'rode' dat ik in de log file terug vind.
Weet iemand hoe ik nu precies kan zien dat Cloud Station Backup die geopende files heeft overgeslagen ?

[Ben(V)]

Die sync.ffs_lock is de lockfile van 'FreefileSyn', je bent dus twee tools door elkaar aan het gebruiken, meestal is dat niet verstandig.

Verder klinkt je tekst alsof je hoop dat het alleen overslaan van de bestanden die openstaan voldoende is.
Als je niet alle bestanden hebt dan is je backup volkomen waardeloos.

De enige manier om van een MSSQL database een remote backup te maken is om lokaal met SQL backup een backup van die database te maken en die backup dan met Cloud Station Backup veilig te stellen.

Overigens zou ik aanraden om al je databases waarvan je een backup maakt, eens te testen of ze werkelijk terug te zetten zijn anders doe je alles voor niets.

[Sylvester]

Bedankt voor de snelle reactie. 

Ik was misschien niet zo duidelijk. Misschien klink ik wel 'hoopvol' en 'gerust' , maar dat is niet zo. Ik gaf ook aan dat er wel degelijk een probleem is.
Die éne MSSQL is zeker een probleem. Ik besef heel goed dat die database kopie niet gaat werken, want bij die overgeslagen documenten zit de DB zelf. Dus als ik die niet heb gaat zeker niks werken.

Nu heb ik net gezien dat die toepassing bij het afsluiten in een specifieke map een file genaamd 'ADMINd-Reservekopie' maakt, en redelijk groot is. Dus ik vermoed dat dit de backup is.
Vermits ik er niks van ken, ga ik alleszins eerst nog eens contact opnemen met de leverancier om de juiste backup strategie te bespreken.
Dit lijkt me de meest verstandige manier... al zeg ik het zelf... 

Ik gebruik 2 backup mogelijkheden, maar niet 'door elkaar'. Die werken 'naast elkaar'. Elk doet zijn eigen ding naar een aparte bestemming, totaal gescheiden. 't Is alsof je met de hand iets kopieert, en dan nogmaals naar een andere map kopieert. Dat mag volgens mij toch geen probleem zijn? Onder het motto van : beter één te veel dan één te weinig.
Ik heb zelfs nog een derde backup voor dezelfde data lopen, die van Windows zelf, voor alle duidelijkheid, ook op een aparte bestemming.

[Ben(V)]

Hoe kun je dan in de cloud backup log 'System heeft het bestand sync.ffs_lock' verwijderd' zien staan?
Dat bestand is de lockfile van freefilesync.

[Sylvester]

dat is een goeie vraag ... 
Effe zoeken....

[Sylvester]

Ik heb hem gevonden, die sync.ffs_lock file.
Van het moment dat FFSync start, plaatst hij die file in de root van de map of het volume waarvan hij een backup gaat maken.
Na afloop van backup verwijdert hij die file weer. Blijkbaar een 'standaard' procedure van FFSync.

En dan is het vanzelfsprekend dat Cloud Station Drive in gang schiet. Want die synct diezelfde map via Cloud Station Server naar een (apart) volume of map op de NAS . Die ziet dat er een 'file' bijkomt, maakt een backup hiervan, de file verdwijnt, en hij verwijdert ze ook. Dit is uiteraard de enige taak van Cloud Station : veranderingen syncen , en dat doet hij goed.

Tot zover klopt dus nog alles en gebeurt er niks abnormaal, behalve dat FFSync geniepig een file genaamd sync.ffs_lock aanmaakt en terug verwijdert.

Maar om even terug te komen op mijn laatste vraag : waarom krijg ik in de log van Cloud Station Server geen melding als hij iets niet kan lezen? Hij slaat het gewoon over....

[Briolet]

Je kunt die "sync.ffs_lock" file bij CS altijd toevoegen aan de lijst van files die niet gesynchroniseerd moeten worden. Dat is altijd zinvol voor dit soort tijdelijke files.

Geniepig zou ik het niet noemen, want het is geen hidden file.