Veeam tapes lezen zonder Veeam B&R

[bucovaina89]

Mijn vraag
Ik ben aan het denken over onze Disaster Recovery procedure. Alsook over hoe we in (ik zeg maar wat) 2035 files

edit:
die op tape geschreven zijn

kunnen restoren die ~15 jaar geleden geschreven zijn met Veeam dat mogelijk tegen dan al lang niet meer bestaat.

Veeam installeren is uiteraard de voor de hand liggende optie maar ik wil een "sure fire" way als alternatief achter de hand hebben. Ik ben specifiek op zoek naar een simpele tool, zo weinig mogelijk dependencies die liefst draait op Windows server 2003,2007,2008,2012,2016,2019,2025, 2029 ... (you get the picture)) die tapes in MTF-formaat kan lezen (Veeam zou ook met MTF formaat werken). Die tool zou overweg moeten kunnen met backups geschreven over meerdere tapes en verschillende backup sessies op 1 tape geschreven.

Om het in UNIX termen te zeggen, ben ik op zoek naar de MS-variant van mt en tar. tar bestaat al sinds eind jaren 70. Correct me if I'm wrong maar ik vermoed dat het perfect mogelijk is om een tar archief van 1979 te lezen met de default tar-binary die nu standaard meegeleverd wordt met eender welk UNIX OS.

Relevante software die ik gebruik
Ja ik ben duidelijk eerder een linux-sysadmin , dus het gebruik van mt(-st) en tar is me bekend. De enige ervaring die ik met tapes in een MS-omgeving heb is Data Protector en Veeam. Zelf files naar tape schrijven/lezen heb ik nog nooit gedaan in Windows.

Ik heb in cmd al ntbackup.exe geprobeerd, maar die blijkt niet meer geinstalleerd op windows server 2012 R2 en lijkt afgaande op de eerste google resultaten een tool uit de prehistorie. Windows Server Backup zou een alternatief zijn. Zou dat voldoen aan mijn vraag? Kan je die gewoon 5 MTF-tapes presenteren en files uit halen?

[ Voor 1% gewijzigd door bucovaina89 op 29-06-2020 09:45 . Reden: verduidelijking ]

[webfreakz.nl]

Waarom wil je een hele VM backuppen, en niet de applicatie(s) en alle bijbehorende gegevens? Je moet namelijk ook een backup hebben van de hypervisor software zelf, inclusief hardware ondersteuning voor oude danwel nieuwe server-hardware, als je dit over 15 jaar nog werkende wilt krijgen.

[bucovaina89]

Omdat ik vermoed dat ik het mezelf een pak moeilijker zou maken om enkel de applicatie te backuppen en mogelijk files/folders niet mee in de backup zet. Hele VM werkt normaal gezien altijd zou ik zeggen. Vergt wel iets meer disk space maar dat weegt imho niet op tegen mogelijk niet alle files hebben en een halve (en dus eigenlijk geen) restore doen.

De hypervisor software had ik idd nog niet mee gerekend!

[Schumaster]

bucovaina89 schreef op maandag 29 juni 2020 @ 13:19:
Omdat ik vermoed dat ik het mezelf een pak moeilijker zou maken om enkel de applicatie te backuppen en mogelijk files/folders niet mee in de backup zet. Hele VM werkt normaal gezien altijd zou ik zeggen. Vergt wel iets meer disk space maar dat weegt imho niet op tegen mogelijk niet alle files hebben en een halve (en dus eigenlijk geen) restore doen.

De hypervisor software had ik idd nog niet mee gerekend!

Hou je ook rekening met beschikbaar zijn van hardware? Kan me voorstellen dat LTO-tapedrives in 2035 ook niet meer heel erg makkelijk te krijgen zijn. En als je een tape-drive op voorraad hebt als onderdeel van je DR-plan, kan je er ook een usb-stickje met Veeam bij leggen

Ook je vervangende tool kan namelijk niet meer beschikbaar zijn in 2035.

[ Voor 4% gewijzigd door Schumaster op 29-06-2020 13:25 ]

[bucovaina89]

@Schumaster : Ik ben nu alles aan het overzetten van LTO-3/LTO-5 naar LTO-8. Zelfs LTO-1 drives (introductie ~2001 denk ik) kan je niet meer nieuw kopen maar zijn verre van zeldzaam op ebay,V&A,/2dehands/marktplaats.

Wat betreft Veeam USB-stick erbij leggen: dat klopt. Ik heb met de restore van LTO-3/LTO-5 die in dataprotector formaat staan, eerst alle (~100) tapes moeten inlezen om de database terug te populaten. Ik ben op zoek naar een mogelijkheid om niet afhankelijk te zijn van een Veeam configuratie/database met welke backup op welke tape staat. Vandaar dus het idee om naast een Veeam USB-stick ook een onafhankelijke tool, die weinig dependencies nodig heeft, eentje die gewoon tapes leest en files uitspuwt .

[The Eagle]

Nofi, maar DR is iets anders als het terughalen van archiefdata. DR zegt iets over hoe snel je weer up en running kunt zijn (al dan niet met acceptabel verlies van data). Dataarchivering praat je over retentietijden, wetelijke bewaartermijnen etc. De kans dat er iets 15 jaar bewaard moet blijven is vrij klein (plus bewaren is iets anders dan terug kunnen halen, al weet ik niet wat de wet daar over zegt )

Having said that: Je wilt je data backup / restore los hebben van je VM's / OS.
En verder wil je denk ik kijken naar iets als een virtuele tape library.

[bucovaina89]

@The Eagle Voor ons als bedrijf zelf is het geen wettelijke eis maar eerder de "eis" van de klant. De kans is erg klein maar als we over 15 jaar iets moeten restoren van vandaag en dat kan niet, hebben we als bedrijf een probleem (en ik als sysadmin ). Het is trouwens zelfs meer dan dat. We moeten een volledig werkende omgeving terug op kunnen zetten met dezelfde binaries/libraries als waarmee toen gewerkt werd.

'DR' is inderdaad geen goede noemer. Inderdaad data-archivering is correcter denk ik

Having said that: Je wilt je data backup / restore los hebben van je VM's / OS.
En verder wil je denk ik kijken naar iets als een virtuele tape library.

Ik wil uitzoeken of ik de tapes die ik nu al geschreven heb, kan uitlezen zonder Veeam te gebruiken. Ik lees mee eens in in wat een virtuele tape library kan betekenen in dit verhaal.

[HTT-Thalan]

Het word al genoemd: Wat jij zoekt is archivering. Vergeet die hele Veeam tool, nog los van het feit dat het totaal niet geschikt is voor archivering moet je uberhaupt buiten de backup gaan kijken.

Als jij data na zoveel jaar nog terug moet kunnen halen is dat puur voor compliancy. En die compliancy kan vaak met uitgeklede data of infra al bereikt worden. Wat voor format heeft de data in kwestie in productie? Is het een database? File share? Welke file types? Mag het archief single-instance zijn of moet het redundant?

[bucovaina89]

@HTT-Thalan : Idd compliancy.

Basically komt het erop neer dat we een hele omgeving waar development in is gedaan willen freezen en mogelijk ooit terug live kunnen opzetten exact zoals ze toen was. Een licentieserver, een Domain Controller, een file share waar tools en applicaties op staan en een Linux VM waar users dus echt ook development op doen.

Dus dan is het al bijna beter om de VM's te exporteren naar .OVA of zo. Die dan op een tape schrijven met tar of ltfs?

Of het single-instance moet zijn weet ik niet maar is een heel goede vraag. Mijn plan was in ieder geval van minstens 2 kopieën op verschillende locaties te bewaren.

[HTT-Thalan]

bucovaina89 schreef op maandag 29 juni 2020 @ 15:36:
@HTT-Thalan : Idd compliancy.

Basically komt het erop neer dat we een hele omgeving waar development in is gedaan willen freezen en mogelijk ooit terug live kunnen opzetten exact zoals ze toen was. Een licentieserver, een Domain Controller, een file share waar tools en applicaties op staan en een Linux VM waar users dus echt ook development op doen.

Ik quote even doelbewust selectief. Je geeft antwoord en gaat gelijk door naar de 'hoe'. Ik wil even stilstaan bij de 'waarom'.

Waarom? Niet om het tegen te spreken, maar om precies te begrijpen waar de vraag vandaan komt en hoeveel wegen naar Rome er bestaan die we nu misschien niet zien.

[bucovaina89]

@HTT-Thalan Waarom? Stel dat over 15 jaar blijkt dat er ergens een fout in ons product zit, willen we (onze klant) exact weten hoe dat kwam en of we die fout al dan niet kunnen reproduceren. Om dat te kunnen reproduceren moeten we dus een werkende omgeving recreëren zoals die x-aantal jaren geleden was.

[Gomez12]

bucovaina89 schreef op maandag 29 juni 2020 @ 15:36:
Dus dan is het al bijna beter om de VM's te exporteren naar .OVA of zo. Die dan op een tape schrijven met tar of ltfs?

Waarom zou .ova over 15 jaar nog in te lezen zijn? Waarom zou er over 15 jaar uberhaupt nog iets als een vm bestaan?

Het hele probleem met jouw vraagstelling is dat die simpelweg extreem raar is. Normaliter archiveer je enkel de info en die info gooi je in een zo breed mogelijk te lezen formaat.

Alleen jij wilt geen info behouden, jij wilt een omgeving behouden. En dat is een heel ander vraagstuk en ik zou hem even goed terug gooien naar de vraagsteller of dat wel is wat hij bedoelt.

Simpel voorbeeldje waar je binnenkort al mee te maken kan hebben, Apple stapt "nu" al af van x86, jouw hele huidige omgeving is x86, is er over 15 jaar nog wel x86 hardware te vinden die jouw omgeving kan draaien?

Of ander leuk vraagje is : Hoe heb je nu je security ingericht? Moeten mensen periodiek hun wachtwoord wijzigen? Zoja, wat denk je zelf dat de kans is dat men die over 15 jaar nog weet?

Er is trouwens een heel belangrijke reden dat men alleen de info in een zo breed mogelijk te lezen formaat gooit, namelijk dat er wel eens een bitje kan omvallen in die 15 jaar. En jij hebt dan niets leesbaar meer, alleen nog maar een paar gigantische binaire blobs, dat kan op vm niveau zijn, maar als je domain controller zijn registry stuk is dan is je hele domain controller (en alles wat eraan hangt) een setje binaire blobs. Hetzelfde als het een driver in je domain controller is.
En dan uiteraard hetzelfde binnen alle developer omgevingen etc.

Kijk, probeer het je eens iets anders voor te stellen, probeer je eens voor te stellen dat je in star trek of star wars (of welke sci-fi dan ook) de boel probeert te restoren, hoe wil je dat doen? Met info gaat dat allemaal wel, maar met omgevingen?

bucovaina89 schreef op maandag 29 juni 2020 @ 17:22:
@HTT-Thalan Waarom? Stel dat over 15 jaar blijkt dat er ergens een fout in ons product zit, willen we (onze klant) exact weten hoe dat kwam en of we die fout al dan niet kunnen reproduceren. Om dat te kunnen reproduceren moeten we dus een werkende omgeving recreëren zoals die x-aantal jaren geleden was.

Nogmaals, ik zou de vraag terug leggen bij die klant, want het kostenplaatje wat hij hier zinnig voor moet gaan betalen staat buiten alle proporties.
Wil je weten hoe zo'n fout kan ontstaan dan volstaat een goede source control en daar een periodieke dump van.
Alleen hoe relevant is het om die fout te kunnen reproduceren? Want cpu's bevatten ook gewoon fouten en moederborden bevatten fouten en drivers bevatten fouten, er zijn in het verleden gewoon bepaalde (ook vm-) bugs geweest die alleen optraden bij type x en y maar niet bij z.
Dus of je moet echt alle hardware ook in opslag gaan gooien (inclusief spares) of je houdt variaties.

En wil je het echt gaan doen zoals je zegt, dan mag je dus of je windows updates uit gaan zetten of bij elke update een nieuwe complete backup gaan maken, omdat anders MS iets opgelost kan hebben wat de bug veroorzaakt / verhelpt waardoor je niets hebt aan je omgeving van 15 jaar terug.

Nogmaals, de klant heeft een wens ok, maar die gaat zijn wens echt wel intrekken als je ook maar een realistisch kostenplaatje hiervoor gaat krijgen.
Want net zoals Veeam niet meer kan bestaan kan ook windows simpelweg niet meer bestaan, of VmWare of ...

[HTT-Thalan]

Wat @Gomez12 zegt inderdaad. Als jij een fout in je product wilt kunnen aantonen, denk ik aan de volgende scenarios:

- het is een fysiek product

dan heb je dus bouwtekeningen, quality control, foto's en dergelijke om dat aan te tonen zoveel jaar na dato

- het is een ontastbaar product zoals software (wat ik vermoed in dit geval)

dan heb je dus een product waar 15 jaar geen wijzigingen of updates meer aan gebeuren? Lijkt me sterk. Met andere woorden, de updates/changelogs over 15 jaar alleen al maken het compleet irrelevant wat er 15 jaar terug in de ontwikkelomgeving heeft afgespeeld. Als er toen een fout is gemaakt is het ófwel allang boven water gekomen, óf in subsequente iteraties opgelost, óf het is waarschijnlijk nooit echt een issue geweest. Situaties zoals de punten-na-de-comma rekenfout in eerste pentiums enzo.

En inderdaad, servers na 15 jaar terug de lucht in gooien . De kans dat je ze nooit meer terug de lucht in krijgt door een hele wáslijst aan praktische zaken maken dit plan praktisch onuitvoerbaar. Je zoekt naar een oplossing voor het verkeerde probleem. Dit is een typisch geval van 'klant vraagt dus wij draaien' zonder naar de waaróm achter de vraag te vragen/zoeken.

NB: voordat je je afvraagt waar haalt die gast zijn uitspraken vandaan: Ik lever al jarenlang dataprotectie oplossingen en doe dat voor een grote gerenommeerde fabrikant met wereldwijd tienduizenden medewerkers (nee, niet veeam).

[The Eagle]

Als een klant van mij na 15 jaar mog iets zou willen restoren, kreeg ie voor het in de lucht houden van die ongein een quote van 1,5 miljoen toegestuurd. Ik moet mijn hardware en software ook betalen en in mirrot houden met die van hem, als hij dat wil dan kan dat maar ik ga er niet voor betalen

Zo deal je met onredelijke klanteisen. Kan wel, kost absurd veel.

[Gomez12]

The Eagle schreef op maandag 29 juni 2020 @ 19:08:
Als een klant van mij na 15 jaar mog iets zou willen restoren, kreeg ie voor het in de lucht houden van die ongein een quote van 1,5 miljoen toegestuurd. Ik moet mijn hardware en software ook betalen en in mirrot houden met die van hem, als hij dat wil dan kan dat maar ik ga er niet voor betalen

Zo deal je met onredelijke klanteisen. Kan wel, kost absurd veel.

Ik zou het absurde getal toch ietsie pietsie hoger leggen dan wat jij nu doet, ik ken genoeg klanten die met jouw bedrag direct zeggen : Is goed wanneer heb ik het...

Alhoewel jij de vraag stiekem veranderd hebt waardoor jij wel een giga-stuk goedkoper uit kan zijn.

Kijk, backuppen en restoren (wat jij zegt) dat is niet moeilijk, gebruik daar gewoon tar etc voor en als die niet meer bruikbaar is tegen die tijd is er een andere tool en zijn er tig conversie-tools.
Dat is grofweg 1x inrichten, wekelijkse / maandelijkse check en voor de rest disk-space kosten. Het is alleen ook redelijk nutteloos aangezien als het goed restored dan hoeft het nog niet te werken vanwege tig andere veranderde dingen.

Alleen de vraag is blijkbaar om die restore ook weer werkbaar te maken door jou om een fout te kunnen reproduceren, oftewel als MS over 5 jaar het voorbeeld van Apple gaat volgen en over gaat naar ARM, dan mag jij ergens x86 hardware gaan stallen voor 10 jaar. Heb je nu xeon-processoren en stopt Intel daarmee, dan mag jij die dus op voorraad gaan nemen om een bug in een Xeon-processor uit te sluiten etc. etc. etc.