Continuous data protection (CDP) szoftver, ingyenes. létezik?

Fórumok

Sziasztok!

 

Létezik olyan ingyenes szoftver, ami rendelkezik CDP képességgel?

https://en.wikipedia.org/wiki/Continuous_data_protection

 

Hozzászólások

Akkor ezek szerint az van, amivel a google-el is juottam. nincs ilyen :(

 

(Amugy ami "talan" alkalmas erre, a Seafile es a Pydio, de ugye ezek nem "igazi" backup megoldasok)

Utoljára ilyet Oracle DBFS-sel (Database File System) láttam, amit FUSE tudott mountolni, alatta pedig természetesen ott volt az adatbázis, ami egy standby szerverre folyamatosan replikált. A redo logfileokban pedig ott volt az összes változás, amiből bármilyen PIT-re vissza lehet állni.

Nagyjából minden rendes adatbázishoz létezik CDP, filerendszerre csak ilyen nyakatekert megoldás van.

Pontosan mi a megoldando feladat? :)

Háttőőőőőőő... nem fog segíteni, de ha a seafile valamiért nem teljesen jó, akkor pl. a resilio sync tud verziózást. Az a "semmilyen modositasol nem lehet lemaradni" persze azonnal bukta, ha pl. másodpercenként tízszer módosul a fájl. Azért szólok bele, mert sok fityfene (pl. owncloud) után ennél kötöttem ki, és kb. "set and forget".

hint: te verziokovetest keresel, nem filerendszert. a problema(d)ra az a megoldas.

esetleg:
https://learn.microsoft.com/en-us/windows-server/storage/file-server/vo…
mondjuk megtamogatva egy ilyennel:
https://www.truenas.com/docs/core/coretutorials/sharing/smb/shadowcopie…

Ezzel a fileok változás követésével az a baj, hogy mi számít változásnak? Ha a program 10000x ír 1 byteot a fájlba, az 10000 változtatást jelent? Vagy minden open-close ciklus egy változás? Esetleg percenként nézi meg, hogy volt-e azóta írás, viszont akkor könnyen lehet, hogy valamilyen köztes állapot kerül mentésre. DB-nél erre valók a tranzakciók, de filerendszeren nem nagyon van ilyen, de ha van is, milyen program használja?

A VSS alapvetően erre való, de az nem backup.

Egyéb oldalról a legtöbb backup megoldás tud sűrűn menteni. Arcserve esetén 15 percenként tudsz menteni és global dedup területre letárolni.

Leginkább egy megfelelő fs és egy lvm replika lehetne a tuti, de mindenképp nas vagy felhő. 

Mekkora a keret? 

DB esetén a motor tudatában van annak, hogy egy tranzakció lezárt, így tisztán tud konzisztens állapotot replikálni. Egy fájlrendszer esetében ez nem triviális, mert az oprendszer csak akkor lehet benne biztos, hogy a fájl konzisztens, amikor az lezárt. Ha elég neked lezáráskor menteni, akkor verziózott fájlrendszer (Windows fileshare tud ilyet) de akár egy rsync is elég. Ha blokkonként kéne, ahhoz végtelen storage kell, és igen lassú lesz, mert gyakorlatilag minden egyes blokk írása egyben egy snapshot is. Igazából tudományos érdekességen kívül sok értelmét nem látnám, mert a snapshot-ok többsége ugye az alkalmazás, de még a fájlrendszer szempontjából is inkonzisztens

A Bacula (ami egyébként egy kitűnű fájl szintű mentési megoldás a mai napig; mi sok helyen használjuk) rendelkezik ilyen képességgel. Egész valószínű, hogy kifejezetten a felhasználói app-ba épített ilyen képesség nélkül ennél tovább a többi mentési megoldás sem tud elmenni.

Bacula Continuous Data Protection

A leírások alapján nem teljesen egyértelmű, hogy csak a fizetős Enterprise vagy az ingyenes Community verzióban érhető el ez a plugin, de a dokumentáció alapján szerintem már a 13-as Community-ben elérhetővé vált (a páratlanok a Community, a párosak az Enterprise verziók), mert a 13-as doksijában már benne van, hogyan kell beállítani, használni.

De az miért baj, ha az Enterprise tudja?

Vagy, meg is kell erőszakolni valamit, meg még ingyen is legyen?

Ha így van szerintem rossz helyen dolgozol...

Szerk: Ja látom, hogy írtad, hogy ingyenes. Én sajnálok minden kollégát, akinek ilyen helyen kell melóznia. Nagyon jó az ingyen szoftver egy csomód dologra, de amire fizetős kell, arra fizetős kell. Ha az a feladat, hogy "oldd meg ingyen mindenképp", az gáz.

Szerkesztve: 2024. 07. 30., k – 11:34

Kisebb problémáim vannak a kérdéssel. ;)

Ez az izé általában nem szoftver, hanem rendszer címszó alatt értelmezhető, ami a hardver+szoftver összehangolt működésével jellemezhető.

A legfontosabb az üzleti cél megfogalmazása, miszerint

  • milyen időtartamú lehet a szolgáltatás kiesése
  • milyen időtartam alatt keletkezett adatok veszhetnek el
  • mennyi a helyreállítási idő

Létezett olyan rendszer, ami a 0-0-0 választ adhatta a fenti kérdésekre: Tandem gépeken a Guardian operációs rendszer. (a tandem ugye olyan bicigli, amin többen ülnek :-))

A kollégák nagyon utálták, mert a szövegszerkesző megnyitása után (--create file) a keletkezett fájlt többé nem lehetett eldobni. :--D

Ha szoftvert keresel, akkor a raid és replikáció kulcsszavak a barátaid. De a legfontosabb a fenti három kérdés megválaszolása! Nem utolsó sorban azt kell megválaszolni, hogy üzletileg mi az amit menteni kell.

Ezzel csak egy bajom van. Ebben az esetben csak azt kell tudni, hogy "mi az adat, aminek verziója van". Az ilyet egyszerűbb az alkalmazás szintjén kezelni, mint tranzakció log, history vagy napló. Mindenesetre a continous backupnak interakcióba kell lépni az alkalmazással. Egy külső rendszert elég nehéz igy megkomponálni. Mert ha nem, akkor itt most azt mondtad, hogy nulla idő alatt verziózva menteni kell az akármit is. ;)

az összes elkészült verziót

Ez nem bonyi, ha define verzió meg define elkészült és oda lehet tenni egy napló sort. Vagy egy adatbázis triggert, bár ehhez mondjuk nem értek.

Windows-on azért ez már előjött valszin komoly formában: https://learn.microsoft.com/en-us/windows-server/storage/file-server/vo…

Ki kell próbálni, dokumentálni, hogy mit tud, és írásban jelezni. Azt is jelezni, hogy ettől függetlenül, ez nem feltétlenül nyújt megoldást. Aztán valami szimpatikus backup megoldással, mondjuk Veeam-mel lehet néhány órás snapshotokat generálni.

Az igazi probléma a HR issue, és nem csak lent, hanem valszin fent is. Ha ugye olyan a munkaerő, hogy atomvillanásokat intéz a szent excelre (ha már mindenképp azzal kell megoldani), akkor ugye felül valszin igen hamar jön a hisztériás roham, hogy ha nem sikerült IT oldalról kezelni (neked ez 5 perc, 2 kattintás, úgyis tudod, megvannak a jó kis titkos megoldások stb.). Ezen a ponton kell gondolkodni, hogy most akkor végülis ez szakmailag mennyire megfelelő, vagy megadni a lehetőséget, hogy találják meg az igényeikhez a megoldást. Nagyon be van rögzülve, hogy az "ájti" az, ami egy darab számítógép, és az mindent megold, aki már látott olyat, az pláne mindent tud, és amelyik cégvezetés ezen nem tud átlendülni, az komoly hátrányba kerül.

A fenti elég sűrűn jön szembe, csak esetleg magasabb szinten csapódik már le, de közös pont, hogy jellemzően nullaforintot szeretnének költeni (a közgázos költségminimalizálást hagyjuk, hiszen rendes autóra hogyhogynem van pénz), és jellemzően koncepció nélkül bele a világba sodródás van. Ha épp egy magát nyeregben érző pénzügyesnek vannak remek ötletei akkor azok jönnek, ha valamit jóságot hallott az illető cégvezető a zismerőstől akkor az, de hogy neki van mondjuk 10-40 alkalmazottja, és akkor oké jó dolog, de ezt rendszerbe tenni komoly pénz, az már nem megy át. "Hiszen ezt ők megcsinálták", meg persze, évek alatt, és sokmillió forint per év költséggel, hogyne, nem csak úgy lett, és tesséknézni? Ott van a helyi támogató ember főállásban, és van néhány külsős, aki nem a napi ügyekkel foglalkozik, na ez rögtön 10x több pénz, amit most tetszik költeni ájtira. Mind1, ezt milliószor leírtam, meg pluszolták, meg más leírta máshogy, egyszerűen fel kell ébrednie a kedves vezetőségeknek, hogy mi a fontos, mert arccal a sárba hullani nem kényelmes.

Az avatatlan szemlélő számára olybá tűnik, hogy téged valaki/valami nagyon megbántott. :(  Ilyenkor el lehet olvasni a joelonsoftware megfelelő passzusát is. Az örök klasszikus szerint, amkor megérekezett az első számítógép, a főkönyvelő gyanakodva méregeti: - Melyik gombot kell megnyomni, hogy kijöjjön a főkönyvi kivonat?

A másik nagy igazság, hogy backupot készíteni a hülye is tud, mert az adatok visszaállítása az igazi művészet illetve érdemes alaposan megtervezni. Ez a MS iromány is részben elismeri a dolog képtelenségét. A leghúzósabb a "realtime backup" kérdésben az, hogy én már láttam ötkilences hardver specifikációt, de szoftvert még nem. Ha egyszercsak elkezd a szoftver hibázni, a "realtime backup" - tárhely hiányában - lassanként körbeér és ott állsz megfürödve a sok példányban  mentett hibás adattal.

Jelenleg van a kezem alatt egy olyan backup rendszer, amely 117 cég komplex ügyviteli rendszerét mentegeti. A szerződésben vállalt kötelezettség legfeljebb az utolsó 20 percben keletkezett adatok elvesztését engedi meg. Ha mondjuk villám csap a szerverbe, attól kezdve ketyeg az óra. A tartalék gép üzembe helyezése és az adatok visszatöltése 1,5-2 óra, ezzel a leállás időtartama is ismert. Ez egy költségoptimalizált megoldás, ennél jobb kényegesen drágább és erőforrássigényesebb lenne.

Aztán ezt a rendszert is leverték, mint a cölöpöt. A backup method zfs snapshot lett, aki készítette még soha nem csinált ilyet. :-D Szóval az én rendszeremet kifizették és használják, de nem ismerték fel, hogy új rendszer helyett elég lett volna 2db diszk az "új rendszer" kialakításához. Hát ennyit az üzleti döntéskről, amikor szakember dönt. :-DD

Ehhez a megállapításhoz nem kell semmilyen megbántás. Ezek a száraz tények.

A mentési rendszer amiről írsz, valószínű SQL DB tranzakciós napló alapú volt - ahogy egy ilyen rendesen megcsinálható. Az "új" meg egy FS alapú, ami még akkor sem lehet ugyan olyan jó, ha történetesen a snapshot módszer app-aware.

Nyilván a Te megoldásod a beletett tudás miatt drágább volt, mint a másik megoldás, ahol pár kattintás pl. egy TrueNAS GUI-n és kész is... És az "új" IT-s azt mondta, ez így jó, a vezető meg készséggel elhiszi, mert ha a szaki azt mondja, hogy jó, akkor jó, pláne, ha olcsóbb. Az "új" szaki meg nem tudja, hol van a saját pöttye a Dunning–Kruger grafikonon (alul), így bártan mondja, hogy jó lesz. A vezető meg mindig (99 vagy több %-ban) csak a pénzt nézi, az olcsóbb nyer. Aztán ha beüt a baj, és szembesülnek vele, hogy pl. a NAV-ba nem lehet mégegyszer beküldeni amit már beküldtek (pedig az ügyvilteli rendszerbe fel kell vinni a kiesett részt), akkor meg vállat von, ez nem az Ő gondja, majd szív vele az alkalmazott meg az IT... Ha meg nem sikerül megoldani, valakit lapátra tesz, jön helyette más, és elkönyvelik, hogy a kirúgott alkalmazott hibája volt, nem a vezetői költség spórolásé... Nincs a magyar vállalkozói szférában semmiféle felelősségvállalási "belső kényszer", morál sajna...

valószínű SQL DB tranzakciós napló alapú volt

Is. A  18 kezelt adattípusból ez csak 2. Az irdatlan mennyiségű log a többi, amit a fejlesztők hibakezelésre használnak. Az előző 30/90 napra bármit megnézhetnek bármelyik rendszeren.

És nem csak, mert a backup szerver - kliensek kapcsolata file alapú. A tárolt adatmennyiség nettó 30TB - bruttó 100TB+.

a Te megoldásod a beletett tudás miatt drágább volt

Ezt egyszer már kifizették. A továbbiakkban nem túl nagy munkával legfeljebb új adattípusokat és mentési módszert kellett volna paraméterezni. Megvizsgáltak egy vásárolható szoftvert, ami labdába se rúgott. A poén: az elkészült megoldás ára és az én árajánlatom kb. ugyanannyi  volt, mint a szoftver ára. A megalapozott döntés úgy nézett ki, hogy az informatikai igazgató értesítette a vezérigazgatót, hogy a megbeszélés (velem) elmarad. Az meg csak lesett. Mellékesen 15 éve megy a backup rendszerem, úgy érzem, már bizonyított. ;) A feladat sem komoly, inkább fontos: A teljes céges infra mentése. (Ahol specifikálták pl. a mentések számát, ami nálam paraméterezhető illetve alapból rolling.)  A győztes cég belső elszámolású, tehát lehet őket sanyargatni, ha hagyják. ;)

Akkor az informatikai igazgató ezek szerint közgazdász végzettségű, és másik cégtől igazolt át ide a magasabb pozíció kedvéért, és csak ez volt éppen nyitott.

Egy profi vezető legalább tárgyal, mert az általában ingyen van (ha az elhasznált időt nem számoljuk, de talán ez esetben ez nem lett volna szempont...).

Az mondjuk már érdekelne, miért kellett a másik megoldás felé hajlania annyira, hogy még látszat versenyt sem tartott. Mivel motiválták meg?

Gondolom, itt a vicc-beli közgazdászra gondoltál. :-D

Nem így van, ö is szakember, vagy volt. Egyszer elárultam a trükköt a vezérigazgatónak: Ha valamilyen szakmai dolgot nagyon nem ért, akkor elsüt valami hülye poént és gyorsan röhög rajta egyet. A vezérigazgató megköszönte a tippet. Mindenesetre a basic *nix világ idegen tőle. A másik tényező a fejlesztő csapat emberei. Nagyon nincs felhozatal, ezért minden döntést görcsösen ő tart kézben. Természetesen azért, mert nincs olyan embere, akire önálló munkát és döntést rá lehetne bízni. Én viszont ahhoz szoktam hozzá, hogy jóval nagyobb rendszert üzemeltetve és programozva a magam ura vagyok. Az eseményeket gyakran sörözés közben kényszerítve meséltem el a főnökömnek, aki csak egyet tudott: nálam mindig minden rendben van és határidőre elkészül. Néha az az érzésem, hogy ezt az igazgató úr nem tudja/fél tőlem/a saját embereihez hasonló színvonalúnak tart.  Egy biztos, ha nekiszegeznéd a kérdést, akkor csak nagyon körvonalazva tudná elmondani mit tud a rendszerem. Így aztán nem képes felismerni azt sem, hogy mire lehet még jó.

A motíváció egyszerű. A "nyertes" a cégcsoporton belüli üzemeltető cég. Nekik könnyű "parancsot adni", aztán vagy sikerül elérni valamit vagy sem. Bár ez utóbbit be nem vallaná senki. Az egyik szempont biztosan az lehetett, hogy nekem ne legyen hozzá közöm. ;)  Ez elvileg helyes döntés, mert így nem egy szakembertől függ minden.

Mindenesetre nem én voltam az egyetlen, aki csak nézett, mint a hülye erre a döntésre.

Teljes mértékben egyetértek!

Az IT az utolsó utáni dolog a ráfordításban, de a No. 1 felhasználást tekintve. Mára egyetlen cég egyetlen tevékényeége sem tud IT nélkül működni (közvetlenül vagy közvetve), ennek ellenére ide nem szánnak sem szakembert, sem pénzt.

Pontosan ezt részleteztük többen, több hsz.-ben, hogy ez az alkalmazói program együttműködése nélkül olyan lesz, mint a kutya vacsorája: vagy van jó verzió mentve, vagy nincs.

Ez tipikusan a "vágjátok ki ezt az erőt, ezzel a heringgel" feladat, ami kiadása után az IT felel érte, hogy 100% megbízhatóan működjön, annak ellenére, hogy igazából megoldhatatlan.

Ez visszaállítási is amúgy, hiszen valójában ez HR issue gyanús. Használtunk valami ilyesmit, de nem kimondottan ez volt a cél, hanem a korai Windows világban ez volt használható. Ez hogy minden legyen, meg ingyen legyen, meg akkor a világot rápakolják valakire, ez inkább azt jelzi, hogy gondolkodni kell merre tovább onnan.

beírtam neked chatgpt-be, viszont nem teszteltem

# Define the directory to monitor and the output directories for JSON and snapshots
$monitorDir = "C:\Path\To\Directory"
$backupDir = "C:\Path\To\Backup"
$jsonFile = $backupDir + "\changes.json"
$snapshotBaseDir = $backupDir + "\Snapshots"

# Create the snapshot directories if they do not exist
if (-not (Test-Path $snapshotBaseDir)) {
    New-Item -ItemType Directory -Path $snapshotBaseDir
}


# Function to save the list of changed files to the JSON file and copy files to snapshot directory
function Save-Changes {
    param (
        [string[]]$changedFiles,
        [string]$snapshotDir
    )

    if ($changedFiles.Count -gt 0) {
        $timestamp = Get-Date -Format "yyyy-MM-ddTHH-mm-ss"
        $snapshotDir = Join-Path $snapshotBaseDir $snapshotDir

        if (-not (Test-Path $snapshotDir)) {
            New-Item -ItemType Directory -Path $snapshotDir
        }

        $snapshot = [PSCustomObject]@{
            Timestamp = $timestamp
            ChangedFiles = $changedFiles
        }
        
        # Copy changed files to snapshot directory
        foreach ($file in $changedFiles) {
            $destinationPath = Join-Path $snapshotDir (Split-Path -Leaf $file)
            Copy-Item -Path $file -Destination $destinationPath -Recurse -Force
        }

        $existingData = @()
        if (Test-Path $jsonFile) {
            $existingData = Get-Content -Path $jsonFile | ConvertFrom-Json
            if ($null -eq $existingData) {
                $existingData = @()
            }
        }
        
        $existingData += $snapshot
        ConvertTo-Json $existingData | Set-Content -Path $jsonFile
        Write-Host "Changes detected and saved to $jsonFile and $snapshotDir"
    }
}

# Create initial snapshot if it does not exist
$initialSnapshotDir = Join-Path $snapshotBaseDir "0"
if (-not (Test-Path $initialSnapshotDir)) {
    Write-Host "Creating initial snapshot..."
    $initialFiles = Get-ChildItem -Path $monitorDir -Recurse | ForEach-Object { $_.FullName }
    Save-Changes -changedFiles $initialFiles -snapshotDir "0"
}

# Array to hold changed files
$changedFiles = @()

# Create the FileSystemWatcher
$watcher = New-Object System.IO.FileSystemWatcher
$watcher.Path = $monitorDir
$watcher.IncludeSubdirectories = $true
$watcher.EnableRaisingEvents = $true

# Event handlers for filesystem changes
$action = {
    param ($source, $eventArgs)
    $changedFiles += $eventArgs.FullPath
    $timestamp = Get-Date -Format "yyyy-MM-ddTHH-mm-ss"
    Save-Changes -changedFiles $changedFiles -snapshotDir $timestamp
    $changedFiles = @() # Reset the array after saving
}

$changedHandler = Register-ObjectEvent -InputObject $watcher -EventName Changed -SourceIdentifier FileChangedHandler -Action $action
$createdHandler = Register-ObjectEvent -InputObject $watcher -EventName Created -SourceIdentifier FileCreatedHandler -Action $action
$deletedHandler = Register-ObjectEvent -InputObject $watcher -EventName Deleted -SourceIdentifier FileDeletedHandler -Action $action
$renamedHandler = Register-ObjectEvent -InputObject $watcher -EventName Renamed -SourceIdentifier FileRenamedHandler -Action $action

try {
    # Keep the script running
    Write-Host "Monitoring directory: $monitorDir. Press Ctrl+C to stop."
    while ($true) {
        Wait-Event -Timeout 1
    }
} finally {
    # Clean up FileSystemWatcher and event handlers
    Unregister-Event -SourceIdentifier FileChangedHandler
    Unregister-Event -SourceIdentifier FileCreatedHandler
    Unregister-Event -SourceIdentifier FileDeletedHandler
    Unregister-Event -SourceIdentifier FileRenamedHandler
    $watcher.Dispose()
    Write-Host "FileSystemWatcher has been cleaned up."
}