none
Zálohování velkých souborů RRS feed

 > 

  • Dotaz

  • Question
    Přihlásit se a hlasovat
    0
    Přihlásit se a hlasovat

    Dobrý den,

    narazil jsem na následující problém: Na Windows Server 2016 Standard je použit zálohovací software VEEAM - zálohuje se denně přírůstkově s týdenní rotací. Vytvoří se jeden soubor s plnou zálohou (velikost kolem 2,5 TB) a pak denní přírůstky cca 20 GB. Zálohy jsou uloženy na NAS, která je připojená přes gigabit ethernet.

    Vznikl požadavek zálohovat i tuto NAS na externí USB disk, který je připojen k serveru. Záloha probíhá zrcadlením pomocí robocopy /MIR

    Problém je v tom, že robocopy začne zálohovat velký soubor plné zálohy, ale nestihne to během celého dne. V noci Veeam provede novou přírůstkovou zálohu a navíc změní jméno velkého souboru plné zálohy (do názvu souboru vkládá aktuální datum a čas). To vede k nějakému zacyklení robocopy a záloha na externí USB disk tak neproběhne.

    Asi není tento koncept nejvhodnější, ale nevím, jak k tomu lépe za daných podmínek přistoupit. Poradíte mi?

    Děkuji. Zdraví Martd.

    mart

    čtvrtek 18. října 2018 6:46
    |

Odpovědi

  • Question
    Přihlásit se a hlasovat
    0
    Přihlásit se a hlasovat

    Problem je IMHO jasne popsany hned v dotazu. Chce to navic chapat logiku veeam agenta a jeho souboru.

    Robocopy kopiruje full VBK od Veeamu. Nestihne to, stale kopiruje a do toho Veeam zazalohuje. Tj. vznikne novy prirustek VIB, nejstarsi prirustek VIB se zapracuje do full VBK = behem kopirovani se robocopy zmeni kopirovany VBK soubor pod rukama.

    Reseni moc neni. Bud bude mit locknuty soubor robocopy (= neprojde zaloha, protoze veeam nebude moci pracovat s VBK), nebo naopak.

    Me zarazi, ze se "nestihne" presunout 2.5TB. 1Gbit/s = 100MB/s = 360GB/h -> 2,5TB za cca 6 hodin idealne. Takze pokud prirustkova zaloha trva par hodin, mam spoustu casu na prenos.

    Kdo to brzdi v tomto pripade? NASka? Pak vymenit. Zdroj zaloh?


    • Upravený Miroslav Tiser středa 31. října 2018 7:43
    • Označen jako odpověď martd čtvrtek 1. listopadu 2018 7:46
    středa 31. října 2018 7:42
    |

Všechny reakce

  • Question
    Přihlásit se a hlasovat
    0
    Přihlásit se a hlasovat

    Sekundární zálohu dělej buď na pásky nebo do cloudu. Vše samozřejmě pomocí Veeamu.

    Nebo můžeš zkombinovat obě možnosti, sekundární záloha na pásku a terciální do cloudu.

    BB

    čtvrtek 18. října 2018 7:17
    |
  • Question
    Přihlásit se a hlasovat
    0
    Přihlásit se a hlasovat
    To by bylo ideální, bohužel je použit pouze bezplatný VEEAM Agent for Windows, který umí naplánovat jen jednu úlohu zálohování.

    mart

    čtvrtek 18. října 2018 7:26
    |
  • Question
    Přihlásit se a hlasovat
    1
    Přihlásit se a hlasovat

    Kdo chce chovat opici, musí mít na banány . . .

    Proč firma šetří na zálohování? Jakou hodnotu mají její data?

    BB

    čtvrtek 18. října 2018 7:30
    |
  • Question
    Přihlásit se a hlasovat
    0
    Přihlásit se a hlasovat
    To je bohužel na úplně jinou diskusi... Ale s těmi banány máte v zásadě pravdu.

    mart

    čtvrtek 18. října 2018 11:01
    |
  • Question
    Přihlásit se a hlasovat
    0
    Přihlásit se a hlasovat
    Problém je v tom, že robocopy začne zálohovat velký soubor plné zálohy, ale nestihne to během celého dne. V noci Veeam provede novou přírůstkovou zálohu a navíc změní jméno velkého souboru plné zálohy (do názvu souboru vkládá aktuální datum a čas). To vede k nějakému zacyklení robocopy a záloha na externí USB disk tak neproběhne...

    Prosím upřesnit to "zacyklení"... ? S jakými parametry běží to Robocopy? Pokud jsi to neudělal, doporučoval bych využít logování průběhu zálohy do souboru (parametr /Log: resp. LOG+: ) a podívat se jestli v něm nebude odpověď na problém. Triviální chybkou bývalo (u méně zběhlých adminů) neurčení parametrů /R příp. /W. A pokud byl nějaký soubor při kopírování náhodou uzamčen, tak se Robocopy snažilo o opakování. A protože výchozí nastavení je milion pokusů po 30 s, tak to vychází na nějakých 57 dnů. Nemá to "zacyklení" původ právě zde?

    BTW. předpokládám, že přejmenovaný soubor zálohy se nesnažíš znovu překopírovat, ale přejmenuješ si jej na tom USB disku a pak jenom zrcadlíš novou zálohu...


    • Upravený J.Nabelek pondělí 29. října 2018 14:53 doplnění, překlep
    pondělí 29. října 2018 14:51
    |
  • Question
    Přihlásit se a hlasovat
    0
    Přihlásit se a hlasovat

    Spíše než "zacyklení" by mělo být zamrznutí. Prostě robocopy nic nedělá, do logu nic nezapíše. Naposledy je tam záznam o naposledy přeneseném souboru.

    Parametry jsou:

    /R:1 /W:1 /LOG+:%log_filename% /NFL /NDL /E /XJ /MIR

    Souborů je jen 8.

    mart

    pondělí 29. října 2018 16:17
    |
  • Question
    Přihlásit se a hlasovat
    0
    Přihlásit se a hlasovat

    Když je to jenom 8 souborů, tak jaký smysl mají ty parametry potlačující logování názvů (NFL,NDL)?

    A není pro Robocopy problém na tom 2,5 TB velkém souboru?

    pondělí 29. října 2018 16:35
    |
  • Question
    Přihlásit se a hlasovat
    0
    Přihlásit se a hlasovat

    Problem je IMHO jasne popsany hned v dotazu. Chce to navic chapat logiku veeam agenta a jeho souboru.

    Robocopy kopiruje full VBK od Veeamu. Nestihne to, stale kopiruje a do toho Veeam zazalohuje. Tj. vznikne novy prirustek VIB, nejstarsi prirustek VIB se zapracuje do full VBK = behem kopirovani se robocopy zmeni kopirovany VBK soubor pod rukama.

    Reseni moc neni. Bud bude mit locknuty soubor robocopy (= neprojde zaloha, protoze veeam nebude moci pracovat s VBK), nebo naopak.

    Me zarazi, ze se "nestihne" presunout 2.5TB. 1Gbit/s = 100MB/s = 360GB/h -> 2,5TB za cca 6 hodin idealne. Takze pokud prirustkova zaloha trva par hodin, mam spoustu casu na prenos.

    Kdo to brzdi v tomto pripade? NASka? Pak vymenit. Zdroj zaloh?


    • Upravený Miroslav Tiser středa 31. října 2018 7:43
    • Označen jako odpověď martd čtvrtek 1. listopadu 2018 7:46
    středa 31. října 2018 7:42
    |
  • Question
    Přihlásit se a hlasovat
    0
    Přihlásit se a hlasovat
    Možná je moje odpověď mimo mísu, ale co třeba zkusit i jen dočasně jiný zálohovací SW, např. Cobian Backup? Sice nezálohuji takové "hardcorové" velikosti, ale osobně na Cobian nedám dopustit - i kvůli rychlosti.
    středa 31. října 2018 10:11
    |
  • Question
    Přihlásit se a hlasovat
    0
    Přihlásit se a hlasovat

    Výpočet teoretické doby přenosu je správný, ostatně při ručním kopírování to file manager odhadne podobně. Po mnoha pokusech jsem ale přišel na to, že po přenesení cca 200 GB náhle prudce poklesne přenosová rychlost a odhadovaný čas začne náhle narůstat až na cca 4 dny. Z časových důvodů jsem to takhle nachytal zatím jen 2x za sebou.

    Zkoušel jsem tedy po stejném kabelu kopírovat místo z NAS na externí disk u serveru jen mezi 2 jinými PC a ono to bylo celkem podobné. Na vině je bohužel nevhodně provedená LAN. Jsou tam v cestě 2 switche, kromě centrálního je tam dobastlený ještě nějaký low-endový 5 portový a ten se zřejmě při velké zátěži nějak utaví. Cvičně jsem tam dal trochu lepší Zyxel a vypadá to, že kopírování běží asi tak +/- 700 Mbit/s (zatím nakopíroval skoro 1 TB).

    Čili z pohledu tohoto dotazu "je asi vyhráno", ale na druhou stranu to klienta zase nepřinutí nějak razantněji zálohování řešit. Vzhledem k tomu, že objem dat má ještě růst, bude asi páska tím vhodným řešením.

    Díky všem.

    mart

    středa 31. října 2018 20:35
    |
  • Question
    Přihlásit se a hlasovat
    0
    Přihlásit se a hlasovat

    A jeste jedna moznost, jak resit: Delat kopii souboru primo v NAS. Vetsina NAS ma nejakou podporu zalohovani na pripojeny USB disk vcetne schedulingu. Pokud to neni nejaky stary lowend, ma NASka USB3 = melo by se pohodlne stihat.

    Tj. neresit na strane serveru, ale na strane zaloh.

    Ale setrivy zakaznik (kolenovrt) je peklo :)



    čtvrtek 1. listopadu 2018 7:39
    |