Op de ADS Server zal in dezelfde directory als waar ADS geïnstalleerd is (C:\Program Files\Advantage 10.10\Server) een programma ADSBACKUP.EXE staan. Met deze tool kan een backup worden gemaakt van de ADS Data Dictionary.
De Syntax van dit commando is als volgt:
adsbackup -p <password> <data dictionary die gebackupped moet worden> <backupdirectory> ofwel
adsbackup -pgeheim e:\ads\data0318\hp_prod.add e:\ads\data0318\backup-prodMiddels optie -p <wachtwoord> dient het wachtwoord welke benodigd is om de data dictionary te kunnen lezen mee te worden gegeven. Dit wachtwoord zullen we hier niet openbaar op het forum zetten, maar, deze zal bij 'de Systeembeheerder' bekend worden verondersteld te zijn. In bovenstaand voorbeeld is het wachtwoord "geheim", welke dan tezamen met -p moet worden opgenomen als "-pgeheim".
Lokatie DataDictionary
Profit werkt met twee separate DataDictionary's:
hp_prod.add bevat de data van de Produktiebestanden
hp_test.add bevat de data van de Testbestanden
De lokatie waar deze DataDictionary staat zal middels de NCONFIG.HRT bekend zijn gemaakt aan Profit, maar, kan óók worden opgevraagd door in een Profitsessie met RightClick de ADS-Info te bekijken.
In dit geval staat de DataDictionary op \\192.168.100.192\ADS\DATA0318.
Let op: Dit betreft hier echter de UNC naam zoals deze op de andere werkstations bekend is. In plaats van een IP adres zou hier ook \\ADSSERVER01\ of i.d. kunnen staan. Het backuppen gebeurt echter op de Server zélf, en daar hebben we de mogelijkheid te refereren aan een normale driveletter. Stel dat die daar op drive E: staat, dan zal de DataDictionary aldaar
E:\ADS\DATA0318\HP_PROD.ADD heten.
Geen indexen in Backup
Als we met
AdsBackup een backup maken, zal de Data Dictionary gebackupped worden, en worden de files (ADT) gebackupped. Merk op dat
AdsBackup géén backup maakt van de indexen! Op zich hoéft dat ook niet, immers, welke indexen er bij welke tabel aktief zijn betreft informatie die in de (gebackupte) DataDictionary zit, en bij het restoren worden de indexen opnieuw aangemaakt.
Produktie- en Test niet naar dezelfde directory Backuppen
Als we met
AdsBackup een backup hebben gemaakt naar een opgegeven directory, dan is het eerste wat opvalt dat alle gebackupte data in één directory wordt geplaatst, en de hele directory structuur (onderverdeling naar Applikatie + Test-/Produktiefiles) niet meegebackupd wordt:
Dus, waar wij zowel voor de Testbestanden als voor de Produktiebestanden een Verkooporderregel (LOVR) tabel kunnen hebben, die wij dan opslaan in \ADS\DATA0318\LO\
LOTF\LOVR.ADT danwel \ADS\DATA0318\LO\
LOPF\LOVR.ADT, plaatst de backupprogrammatuur alles in dezelfde directory. Hieruit volgt vanzelf dat als we én een backup van de Produktiebestanden maken én een backup van de Testbestanden, we dit niet naar dezelfde moeten backuppen, immers, daar kan maar één LOVR.ADT staan. De ene tabel zou de ander doen overschrijven.
Advies is derhalve om aan de directory waarin de DataDictionary staat, twee subdirectory's te koppelen: backup-test en backup-prod;
Backup vervolgens hp_test.add naar \backup-test en hp_prod.add naar \backup-prod.
Backup niet te openen in Data Architect
Hoewel het erop lijkt dat we nu een nieuwe DataDictionary hebben in de backup-prod directory, en daar ook .ADT files staan, kunnen we deze DataDictionary niet openen in de Advantage Data Architect. Op zich ook wel logisch, immers, de ADT file werkt met auto open indexen, en de indexen die benodigd zijn om de ADT te kunnen openen waren niet gebackupd.
Let op: Mocht u bovenstaande tóch proberen te openen, vergeet dan vooral die connectie niet te sluiten na uw test, anders kan er géén restore worden uitgevoerd. De restore vereist de Data Dictionary voor allééngebruik.
Restore
Het restoren van een eerder gemaakte backup gebeurt middels hetzelfde commando
AdsBackup.EXE, door opgave van een extra optie
-r.
De syntax is:
adsbackup -r -p <password> <data dictionary die gerestored moet worden> <lokatie data dictionary waarnaar gerestored moet worden> bijvoorbeeld:
adsbackup -r -pgeheim e:\ads\data0318\backup-prod\hp_prod.add e:\ads\data0318\hp_prod.addBovenstaand commando restored de eerder gemaakte backup uit de e:\ads\data0318\backup-prod directory, en schrijft deze terug naar e:\ads\data0318.
Let op: Waar bij de backup enkel de éérste lokatie een DataDictionary bevat (en de tweede slechts een directory), moet bij de Restore twee maal een DataDictionary worden opgegeven. HP_PROD.ADD komt dus 2x voor in de opdrachtregel!
Let op: Onderstaande hoofdstukken zijn per 12 augustus 2019 komen te vervallen; zie topic http://ha1.heartprofit.nl/profit/index.php?topic=29357.0.
Restore naar andere lokatie
Hoewel bovenstaande restore zou moeten werken, overschrijven we door te restoren naar dezelfde directory, onze huidige dataset. Dat is natuurlijk 'gevaarlijk'. Het is veiliger de DataDictionary te restoren naar een nieuwe lokatie.
Let op: Hiervoor dient u vanuit Profit éérst een nieuwe DataDictionary aan te maken!.
Dit heeft te maken met het feit dat (zoals eerder genoemd) het AdsBackup programma niets van de hele directory struktuur opslaat. Intern bewaard ze in de DataDictionary wel de lokatie van de tabellen (ADT) en de lokatie van de indexen (ADI), maar dat doet ze alleen voor die tabellen waar ook daadwerkelijk iets van gebackupd is. Dus, als we een backup maken van de LOVR.ADT uit de Produktiebestanden (..\LO\LOPF\LOVR.ADT) dan zal de restore wel degelijk weer een ..\LO\LOPF directory aanmaken, en daar de LOVR.ADT in terugzetten. De directorystruktuur bevat echter ook een ..\LO\LOTF voor de testbestanden, en zodra daar géén files uit gerestored worden, wordt die directory ook niet opnieuw aangemaakt. Uiteraard geldt dit ook voor directory's zoals AD, NT, PK, SY voor welke Subapplikaties misschien helemaal nog geen bestanden als "ADS" zijn gedefinieerd; ze files komen dan niet in de backup te staan, en dus zal een restore de directory's niet opnieuw aanmaken. De eerst volgende keer als we een nieuwe tabel zouden willen opnemen in de ADS Data Dictionary, zou dit foutlopen 'omdat de hiervoor benodigde directories niet (meer) bestaan.
In Profit kunnen we zélf een nieuwe Data Dictionary genereren voor ADS. In principe zouden we er aan één voldoende hebben, en zouden we nooit verder hoeven te komen dan een directory \ADS\DATA0001 (immers, aan één dataset hebben we voldoende). Als we echter nóg een keer een DataDictionary aanmaken, zal de DATA0001 automatisch worden opgehoogd naar DATA0002 (en zo zitten we in ons testvoorbeeld al op DATA0318). Het aanmaken van een nieuwe (lege) Data Dictionary doen we vanuit Hoofdmenu-9-5-8-1-1. Onze DATA0318 wordt hier automatisch verhoogd naar DATA0319, en we kunnen volstaan met F1.
Op de ADS Server zal in de directory E:\ADS een nieuwe Subdirectory DATA0319 zijn aangemaakt, met daarin twee DataDictionary's (Test- en Produktie), de hele directory struktuur, maar verder geen ADS tabellen of indexen. Vervolgens kunnen we onze restore veilig uitvoeren naar de nieuwe directory, zónder daarmee onze oude data te overschrijven.
adsbackup -r -pgeheim e:\ads\data0318\backup-prod\hp_prod.add e:\ads\data0319\hp_prod.add
Let op: Merk op dat als we naar een nieuwe lokatie restoren, we natuurlijk wel voldoende diskruimte hiervoor moeten hebben !
Niet alleen voor de te restoren ADT's, maar óók voor de indexen die door de restore weer opnieuw opgebouwd worden.
Restore bekijken[/s]
De restore is nu teruggezet in de nieuw gekreëerde e:\ads\data0319\hp_prod.add.
Als we de restore enkel gedaan hebben om even te testen hoe e.e.a. werkt, dan zouden we deze hp_prod.add uit de data0319 directory nu gewoon via de Advantage Data Architect moeten kunnen benaderen.
In mijn testvoorbeeld had ik één Verkooporder voor vandaag toegevoegd toen ik een backup ging maken. Tijdens het backuppen heb ik de DataDictionary en een paar tabellen in de Advantage Data Architect geopend gehouden. Ook was er nog een Profitsessie aktief waarin ik gedurende de backup nog een order met 30 regels heb toegevoegd. Nu de restore bekijkend is de 1e order inklusief alle orderregels aanwezig. De 2e order inklusief de regels staan er niet in (voor de duidelijkheid: dit betreft twee tabellen (LOVO en LOVR) die consistent met elkaar gerestored zijn).
* Backuppen terwijl er gebruikers aan het werk zijn lijkt daarmee mogelijk te zijn.
* De backup zal echter niet achteraf nog een nieuwe doorloop doen om te kijken of er nog records bijgekomen zijn.
Of we ook mogen konkluderen dat e.e.a. met een tijdstempel werkt, en alles wat ná het starten van de Backup is toegevoegd in consistentie niet gebackupd is, kan nog niet gesteld worden. Met dat er ook een mogelijkheid bestaat om Differentiele Backups te maken (zie verderop) zouden we kunnen bedenken dat ADS intern zo werkt dat ze precies weet wat er wanneer is aangepast.
Met de beschrijving van deze procedure kunt U uw eigen tests uitvoeren.
Restore aktiveren als nieuwe Dataset
Door in de
\FOX\LO\LOPW\NCONFIG.HRT de regel
ADSDDPATH=\\192.168.100.192\ADS\DATA0318 te wijzigen in
ADSDDPATH=\\192.168.100.192\ADS\DATA0319 kunnen we de nieuwe DataDictionary aktief maken. Iedere gebruiker die daarna Profit opstart, zal automatisch verbinden met de nieuwe Data Dictionary. Desgewenst kunnen we dit kombineren met de mogelijkheid Profit op te starten voor gebruik, waarna de Systeembeheerder eerst zelf kan kontroleren of alles naar tevredenheid werkt met de teruggehaalde data, om daarna pas Profit vrij te geven voor gebruik.
Als we naar tevredenheid kunnen werken in de teruggehaalde data, zou de oude DataDictionary (DATA0318) kunnen worden verwijderd om diskruimte vrij te maken; vanaf nu werken we dan met een nieuwe DataDictionary (in DATA0319).
Merk op dat er verschillende redenen kunnen zijn om een restore uit te voeren. In het ergste geval begeeft een disk het, en moeten we terug naar de oude situatie. In zo'n geval kan de disk worden vervangen, maken we een nieuwe (lege) Data Dictionary aan (die dan gewoon dezelfde naam mag hebben als de oude), en voeren we de restore uit; omdat e.e.a. op een nieuwe disk staat, overschrijven we toch niets. Ditzelfde geldt als we bijvoorbeeld onze data van de ene ADS Server zouden willen verhuizen naar een andere (snellere) ADS Server. Op de oude server maken we een backup, op de nieuwe server genereren we een nieuwe lege data dictionary en voeren we de restore uit, en daarna maken we de nieuwe lokatie de aktieve DataDictionary.
Gedeeltelijke Restore
Ongetwijfeld ook mogelijk via de AdsBackup.exe, maar anders in ieder geval via de Advantage Data Architect, is het ook mogelijk om één (of meerdere) specifieke tabellen te restoren. Nou geldt sowieso al dat je altijd heel erg moet oppassen als je een gedeelte terughaalt van een backup, immers, je bent daarmee in staat een inconsistente dataset te kreëren. Stel maar voor je wat er gebeurt als je een oude 'Debiteurentabel' gaat terughalen, maar ondertussen al wel Verkooporders hebt gemaakt op nieuwe Debiteuren die nog niet bestonden in de teruggehaalde tabel.
Maar, áls dit nodig was, én je kon overzien wat je aan het doen was, dan stelde dit bij de normale VFP tabellen weinig voor.
Je kon de ene tabel terughalen van de backup, die restorede je in een andere directory, en via de Verkenner knipte-/plakte je het bestand wel terug naar de lokatie waar ze zou moeten staan (\FOX\LO\LOPF\LORD.DBF).
Bij ADS bestanden werkt dit niet zo eenvoudig. De Data Dictionary weet van zichzelf welke tabellen daarin staat, en waar deze op disk zijn opgeslagen. De tabellen weten van zichzelf weer welke indexen erbij horen, en waar deze zijn opgeslagen. Zouden we een naar e:\ads\data0319\lo\lopf\lovr.adt gestorede Verkooporderregel tabel via de verkenner doorkopieren naar e:\ads\data0318\lo\lopf\lovr.adt, dan is de tabel daarna niet meer te openen.
Een restore van een enkele tabel zal vermoedelijk altijd direkt moeten worden gerestored naar de Data Dictionary waarin de tabel ook daadwerkelijk weer gebruikt gaat worden; achteraf kopiëren met de verkenner werkt in ieder geval niet.
Advantage Website
Voor meer informatie zie
http://devzone.advantagedatabase.com/dz/webhelp/advantage9.1/advantage_concepts/advantage_functionality/backup/adsbackup_utility.htmHierin zal met name het hoofdstuk over Differentiële Backups handig zijn. Door eerst met optie
-a een differentiële backup te initialiseren, kan daarna middels optie
-f een backup worden gemaakt van alles wat t.o.v. de laatste keer gewijzigd is. Hierdoor hoeft dan niet de hele tabel opnieuw gebackupd te worden. Zo zouden we 's nachts een volledige backup kunnen maken, om vervolgens om het (half?) uur enkel de erbij gemaakte mutaties te backuppen.
Met
adsbackup -a -pgeheim e:\ads\data0318\hp_prod.add e:\ads\data0318\backup-prod initialiseren we een differentiële backup.
Met
adsbackup -f -pgeheim e:\ads\data0318\hp_prod.add e:\ads\data0318\backup-prod backuppen we enkel de wijzigingen die sinds de laatste backup erbij zijn gekomen.
Om dit eens te testen, maak ik eerst een backup met -a. Vervolgens voeg ik één nieuwe order toe, en maak een nieuwe backup met -f. Deze is in een fraktie van een sekonde klaar. Nu verwijder ik twee Verkooporders, en maak een nieuwe backup met -f. Ook deze is in een fraktie van een sekonde klaar. Als laatste, net als hierboven beschreven, een restore naar een nieuwe lege data dictionary.
Dit ziet er prima uit. Alle orders (t/m gisteren) staan er netjes in, de nieuw toegevoegde orders (en met -f gebackupd) staan erin, en de verwijderde orders zijn ook in de restore netjes verwijderd.
Let op: Dergelijke differentiële backups werken alleen met ADT's. Profit hanteert default ADT als formaat (maar staat ook ADS_VFP toe; deze zal niet gebruikt moeten worden.
