Archiveren fileserver (replicatie/incrementals)

[basset]

Wij hebben momenteel een windows fileserver met een archief partitie (read/only), die wij repliceren naar een andere server. Nu zou ik eigenlijk de archief folder voor iedereen beschrijfbaar willen maken en op de replicatieserver zou ik eigenlijk willen dat er wel bestanden toegevoegd kunnen worden via de replicatie, maar niet verwijderd.

Dus ook als men een bestand toevoegt met een naam die al bestaat, dat beide versies bewaard worden. Nu kan dit bijvoorbeeld met incrementele backups, maar ik zou dit bij voorkeur in replicatie opgelost willen zien.

Professionele tooling excelleert in de meest complexe marketing b######t waarbij ik door de bossen de bomen niet zie.

Het gaat hier om TB's, niet om enkele honderden GB's.
Ik weet niet hoe microsoft hier tegenwoordig mee kan werken, maar voorheen was ik er niet van overtuigd.

Een andere oplossing kan zijn dat delen van folders actief verplaatst worden als er een x tijd geen schrijfacties meer hebben plaatstgevonden in een deel van die folder. Nu lijkt dit mij lastig, omdat systemen soms een bestandje achterlaten in folders als ze er remote naartoe gaan. Ook backupsoftware doet volgens mij iets met bestanden in de scan fase.

Kortom, nu handmatig eens in de x maanden is een rotklus die geautomatiseerd moet kunnen worden, het liefst zodanig dat gebruikers er geen last meer van hebben.

Idealiter zie ik een nieuwe indeling, waarbij dus op het eerste gezicht geen folders meer verplaatst worden, maar onderwater weinig benaderde bestanden, toch naar een andere storage verhuist worden. Echter voorzie ik hier allerlei problemen met het maken van consistente backups.

Iemand tips voor software of whitepapers die dit onderwerp behandelen?

Ik zit nu naar onepass te kijken van commvault, aangezien we al commvault gebruiken.

[MAX3400]

Geen idee want je bent een beetje je eigen glazen aan het ingooien:

- we hebben nu READ ONLY
- die repliceert naar B
- nu willen we READ ONLY opheffen
- maar bij replicatie niets verwijderen
- bestanden toevoegen met zelfde naam, meerdere versies bewaren

Leg me eens uit: je hebt nu ergens bestand Geboortekaartjes.docx en nou ken ik Windows enigszins maar hoe voeg ik een nieuw bestand toe met de naam Geboortjekaartjes.docx zonder dat Windows daartegen in opstand komt?

In ieder geval; als je op B niets wil verwijderen; draai je toch gewoon elke nacht een robocopy-scriptje, kopieert verschillen van A naar B maar kopieert niet & logt welke target-bestanden al bestaan (of anders zijn dan de source) ?

Het kan zijn dat ik jouw vraagstelling volledig verkeerd interpreteer maar als het zo'n rotklus is en je geen consistente backups kan maken nog voorbeelden geeft van bestaande/gevonden oplossingen en hun nadelen, is het een beetje onduidelijk voor mij wat je nu precies probeert te bereiken.

[basset]

Ja,

Het is verwarrend en moeilijk onder woorden te brengen. Dat ben ik wel met je eens Hier wordt ik wel vaker van beschuldigd. Wat ik probeer is mensen zelf verantwoordelijk te maken door ze alles zelf in een archief te kunnen laten zetten. Wat ik echter niet wil, is dat mensen, als ze een bestand weggooien hier, dat deze op de co-locatie ook weggegooid wordt. Dus feitelijk moeten er op de andere locatie alleen maar bestanden toegevoegd worden, ook als ze gewijzigd worden, moet het origineel blijven bestaan.

Nu zie ik hier meteen een probleem, want ik kan nu hier lokaal niet de archiefbackup meer garanderen en, dus moet ik dat op de andere locatie in gaan richten....wat geen optie is. Het kan soms zo simpel zijn.

Dus moet ik toch gaan kijken naar een oplossing als Simpana Onepass icm onze backup etc.

Bedankt voor de spiegel

[MAX3400]

Kan je dan niet, out of the box gedacht, iets met Git gaan doen (of een andere versioning tool)?

Alternatief is Sharepoint (want automatisch versioning, ook bij wijzigen van bestaande bestanden) maar daar zit vrij veel configuratie aan; Sharepoint wordt te vaak gebruikt als veredelde fileserver en dat is het namelijk absoluut niet.

[basset]

Daarvoor is de structuur die wij gebuiken mogelijk niet helemaal geschikt. Sharepoint gaat hem ieder geval niet worden idd. Git verwacht ik ook niet. Dit maakt het voor collega's nodeloos complex vermoed ik. Ik wil nagenoeg geen impact voor de collega's.

SVN/GIT achtige oplossing zijn wel voorbij gekomen hoor, maar is meer voor relatief kleine omgevingen voor mijn gevoel en niet echt geschikt voor archiveren.

[DiedX]

Ik blijf het een vreemd verhaal vinden. Je wil dus een delta bewaren, maar voor hoe lang?

Is een optie als FreeNAS, en dan ZFS snapshots daarop een optie?

[The Eagle]

Met snapshotten kom je al een heel eind. Een beetje storageoplossing kan prima wat jij wilt. Maar een windows/linux OS is daar een stuk minder voor gemaakt.
En om hoeveel TB gaat het? Zijn het er twee of 2000?

[ Voor 24% gewijzigd door The Eagle op 02-11-2017 11:21 ]

[Question Mark]

The Eagle schreef op donderdag 2 november 2017 @ 11:20:
Met snapshotten kom je al een heel eind. Een beetje storageoplossing kan prima wat jij wilt. Maar een windows/linux OS is daar een stuk minder voor gemaakt.

Dit is exact waar previous versions voor gemaakt is in Windows..

@TS:

Wat is exact het doel van de replica. Moet daar ook actief van gelezen worden? Indien niet, dan zou ik beide systemen opnemen in een DFS replica groep. In de bijbehorende DFS namespace enable je dan alleen het target naar het "primaire" systeem.

Zet de share rechten naar de replica voor gewone users nog even naar read en dan ben je er eigenlijk wel.

Bij uitval van de primarie server hoef je dan maar twee aanpassingen te doen. (sharerechten en dfs namespace target).

[basset]

Replica is puur voor DR doeleinden. Mocht de fileserver afsterven of het pand ontploffen, kunnen we direct beschikken over een fileserver......mits we niet in het pad zaten toen het ontplofte.....

[Question Mark]

Dan zou ik even naar DFS kijken, in combinatie met previous versions...

Misschien heeft het wat beperkingen ten opzichte van een betaalde oplossing, maar je zult een heel eind komen..

[The Eagle]

basset schreef op donderdag 2 november 2017 @ 12:11:
Replica is puur voor DR doeleinden. Mocht de fileserver afsterven of het pand ontploffen, kunnen we direct beschikken over een fileserver......mits we niet in het pad zaten toen het ontplofte.....

Hoe is je setup verder? Zijn het physicals of VM's? En wat draait er qua storage onder? Indien VM's weet ik nog wel een hele mooie oplossing

[Gomez12]

Question Mark schreef op donderdag 2 november 2017 @ 11:43:
[...]

Dit is exact waar previous versions voor gemaakt is in Windows..

Het probleem met dit vraagstuk is dat ik vermoed dat het in wezen veel & veel complexer is dan dat de TS zelf verwacht.

Wat nu als ik een dbase bestand van 2 Gb op die schijf zet en daar actief in zit te editten, dan vlieg je zo door je previous versions schijfruimte heen. Terwijl je het in feite voor dat dbase bestand niet zo relevant vind, maar wel voor je word-bestandjes etc die compleet weggedrukt worden als de ruimte voor previous versions vol is.

Wat ik in de praktijk bij dit soort vraagstukken voornamelijk zie is dat er een heleboel lagen van archiveren gewenst zijn terwijl previous versions meer een one-size fits none oplossing is.

Dus bijv van word-bestanden die handmatig gecreeerd worden daar wil je een archief van zeg een maand in hebben, maar xml-bestanden aangeleverd door de klant daar wil je slechts een archief van een week voor hebben, plaatjes die bij externen opgehaald worden daar wil je totaal geen archief van hebben.

[Rolfie]

moeten gebruikers de oude versies terug kunnen halen? Of is als de admin dit kan voldoende?
Hoelang wil de je oude versies bewaren?

Je bent eigenlijk een een Document Management Systeem aan het uitvinden.
Het is in iedergeval geen archief meer, zoals je met de data straks om gaat.

Je hebt dus een datastructuur waar je versies in wilt bijhouden?

En over hoeveel data praten we nu echt?
Hoeveel mag het kosten?
Hoeveel delta verwacht je per keer?
Moet iedere versie bewaard blijven of alleen de laatste tijdens de backup?

[The Eagle]

Gomez12 schreef op donderdag 2 november 2017 @ 14:41:
[...]

Het probleem met dit vraagstuk is dat ik vermoed dat het in wezen veel & veel complexer is dan dat de TS zelf verwacht.

Wat nu als ik een dbase bestand van 2 Gb op die schijf zet en daar actief in zit te editten, dan vlieg je zo door je previous versions schijfruimte heen. Terwijl je het in feite voor dat dbase bestand niet zo relevant vind, maar wel voor je word-bestandjes etc die compleet weggedrukt worden als de ruimte voor previous versions vol is.

Wat ik in de praktijk bij dit soort vraagstukken voornamelijk zie is dat er een heleboel lagen van archiveren gewenst zijn terwijl previous versions meer een one-size fits none oplossing is.

Dus bijv van word-bestanden die handmatig gecreeerd worden daar wil je een archief van zeg een maand in hebben, maar xml-bestanden aangeleverd door de klant daar wil je slechts een archief van een week voor hebben, plaatjes die bij externen opgehaald worden daar wil je totaal geen archief van hebben.

En dat is nog maar een deel van het probleem. Want hoe zorg je voor een consistente backup/restore? Moet dan op de zelfde tijd, dat is bijna niet te syncen. En bij een restore heb je ook weer andere volgnummers en klopt je filesystem niet meer. Daarom dus ook: dit soort zaken in de DB opslaan

[deadlock2k]

-

[ Voor 100% gewijzigd door deadlock2k op 06-08-2021 15:30 . Reden: halve zin vergeten ]