Restic alternativa, ami nem titkosit

Linux-haladó

Sziasztok!Adott ket tavoli telephely VPN-el osszekapcsolva. Az egyik backupol a masikra Restic segitsegevel. A snapshot alapu, deduplikacios backup tok jol mukodik a Resticel, viszont a mivel a Restic alapbol (es kikapcsolhatatlanul) titkositja az adatokat, ezert a masik oldalon levo VDO backendnek igy nem sok hasznat veszem... Letezik olyan backup megoldas CentOS ala (Cockpit integracio nem lenne rossz...) amivel a restichez hasonlo modon tudok backupot kesziteni, de nem titkosit?

  • 152 megtekintés

Ma teszteltem a borgot es nyert :)

 

Igazabol foloslegesse is tette a VDO-t az egesz ala, hiszen gyarilag tomorit es deduplikal, szoval semmi ertelme meg egy plusz retegnek.

 

Egy 2 gigas tomoritetlen SQL fajlal teszteltem ("halas" tesztfajl), a ket telephely kozott egy 100Mbit-es berelt vonal van. lz4-el kozel kihasznalta a teljes savszelt es olyan 230MB lett az eredmeny, de vegul maradtam a zstd-bel, (kb 110 megara huzta ossze) ezzel csak olyan 20-30Mbit-et tud (bar gondolom a CPU a szuk keresztmetszet) de eleg ennyi is boven.

 

SQL-t lecopyzva es par sort atirva csak kb par kilobyte-ot masolt, szoval a deduplikacio szepen mukodik.

Tetszik benne, hogy vannak teljesen kesz binarisok, nem kell szivni fuggosegekkel, stb... Bar nem teljesen tiszta nekem, hogy a fogado oldalra miert kell telepiteni a borgot.. ezt valaki leirhatna (ha addig nem talalom meg a hiv. doksiba)

A restore meg nagyon kiraly! Jol sejtem hogy itt is van meg valami kis "trukk"? Mert sokkal gyorsabban restore-ol, mint a fajl meretebol es a net sebessegebol kovetkeztetni lehet :)  (restic ugye csak backup iranyba tud deduplikalni, restore az sima fajl copy)

Szoval kosz a tippet! Rendes GUI-t igaz nem talaltam hozza, de OMV ala van egy jo kis plugin, az nekem pont jo is.

gondolom ezert kell mind a ket oldalra: 

Deduplication based on content-defined chunking is used to reduce the number of bytes stored: each file is split into a number of variable length chunks and only chunks that have never been seen before are added to the repository.

Amolyan rsync szeruen:

The sender computes the checksum for each rolling section in its version of the file having the same size as the chunks used by the recipient's. While the recipient calculates the checksum only for chunks starting at full multiples of the chunk size, the sender calculates the checksum for all sections starting at any address. If any such rolling checksum calculated by the sender matches a checksum calculated by the recipient, then this section is a candidate for not transmitting the content of section, but only the location in the recipients file instead. In this case the sender uses the more computationally expensive MD5 hash to verify that the sender's section and recipient's chunk are equal. Note that the section in the sender must be not at the same start address as the chunk at the recipient. This allows efficient transmission of files which differ by insertions and deletions. The sender then sends the recipient those parts of its file that did not match, along with information on where to merge existing blocks into the recipient's version. This makes the copies identical.

kozben meglett:

 

What is the difference between a repo on an external hard drive vs. repo on a server?

If Borg is running in client/server mode, the client uses SSH as a transport to talk to the remote agent, which is another Borg process (Borg is installed on the server, too). The Borg server is doing storage-related low-level repo operations (get, put, commit, check, compact), while the Borg client does the high-level stuff: deduplication, encryption, compression, dealing with archives, backups, restores, etc., which reduces the amount of data that goes over the network.

When Borg is writing to a repo on a locally mounted remote file system, e.g. SSHFS, the Borg client only can do file system operations and has no agent running on the remote side, so every operation needs to go over the network, which is slower.