Re: Huge archive and last slice
Denis Corbin <[email protected]> Tue, 12 Dec 2023 18:56:03 +0100
| Newsgroups | gmane.comp.sysutils.backup.dar.support |
|---|---|
| Message-ID | <[email protected]> |
On 12/12/2023 08:10, Raoul Bonnal wrote: > Dear Denis, Hi Raoul, > > thanks for your software. you're welcome > > My scenario: I must archive scientific data and eventually retrieving a > small portion of the data. The data are huge, several tens of TBs so the > slices are very useful because we can divide the global archive in > pieces, then with the catalog we can identify the exact slice(s) in case > of need. Data (archives/slices) can be deposited in a remote site, so > optimizing the transfer (retrieving) of the data is a priority. > > At first I thought that the catalog and the slices of interest were > enough. Then I realize from the dar messages, and confirmed by a msg on > the ml that also the last slice is required. You can avoid relying on the last slice (which contains the table of content or the archive) using -A option while extracting, listing or testing your archive: assuming you have big.238.dar and big.373.dar slices (from a 500 slices archive) which slices you know to contain the totality of the files you want to extract, and also have cat_big.1.dar the isolated catalog of this big archive: dar -x big [-g/-P/... filtering options] -A cat_big dar will load the table of content (aka catalogue) from cat_big and try to restore the files that match the filter. If they are all located in slices 238 or 373 which are present in the local directory, dar will find them and use them without asking the user and without the user required to download anything else. You can also automate the process, by mean of -E option and do not bother about which slice to download, dar will do it for you: dar -x big [-g/-P/...filtering options] -A cat_big -E "rm %b.*.%e ; scp [email protected]:/some/path/%b.%N.%e ." -E option will first remove any old slices from the archive which basename is %b (substituted by what you provided to -x/-t/-l/... option) then it will call scp (adapt to the protocol you rely on) to fetch the needed slice. As dar reads slices in increasing order, a given slice will not be asked more than once (dar could ask the last slice a second time if you were not relying on the isolated catalog) Of course and as you know, you only need the isolated catalogue to know the slices needed for a file or even for several files: assuming you need all files in subidrectory usr/share you get the list of slice to fetch by using: dar -l cat_big -g usr/share -Tslice | tail -n 3 I guess, the confusion cames from the fact the overall size of the archive is not know from the isolated catalog and to get this information you need the last slice. But except that, the isolated cataloge holds all the necessary information needed to restore any file data, EA and FSA stored in the archive, including the global offset and the slice layout from which dar calculates the slice information (and file offset in the slice) > > The point is: if the last slice is 500GB+ I need to keep it available or > download it every time a file/directory must be recovered. from the previous explanation, you now know that it is not necessary to download the last slice, the isolated catalog is sufficient for that. > > > I was wondering if it is possible to "extract" from the last slice only > the relevant information needed for the recovery. I can understand that > is it convenient to keep them in the last slice because usually it is > the smallest one, but in case of huge archives its size can be relevant. Yes, the is precisely the isolated catalog. > > > PS: I must thanks John Goerzen for his support in setting up dar > w/threads during my tests. > > > Bests, > > R. > Cheers, Denis
OpenPGP_signature.asc
(application/pgp-signature, 840 B)
-----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEVeSEpqXFvH9T9/cuqLFBYNNrO6cFAmV4nrMFAwAAAAAACgkQqLFBYNNrO6eA 6A//VCsv0+Kog5cC56f7XsokkyZ4E6ks7d9zdefLhgJxCtEeY8LJT0A3dhTPX+uu+PpaTDQYwiXC JfpvTWWUOHNC5guYiYrbP6GcjWKIRCXDGdfEThjmM/msCTRIkYGu7lzEAtlK6u66+Su9vo7TI2L0 lmODN6SHcXahQA0pR4b+Zi4XCnJmTmO8lNwfImbqoHHcKbykDlWxSLvY5l/W4dBxipNko6W/QKG2 z2DLrHVDAorYi4gFz2t0QZoHDX8khaBh0NZN/foRVY+Tug2WI+E3ZeJCXcSSVc0sjQNTkbTW91Yf pkPppbPrSsFelJAbAil5PesqaKuvIjpproAQSs2uV2bF8odLU/6QOMugtA4jXD0/iONYLSWvGNBb ICNpjS3C5EdBCHr+wRSC0FyB7bL22Qru/ZjCMpNI3zV7SBv442zP9gEl3QzNxsZEie+VOCG/mkz6 zyX7ZrnYMz/nLiDSJBxBMVv2O4D/KVvtKo/1R64nIN6NIswS8WO1nDVigbzCuRUXs5MnvU0oncs2 dZ5lZSEvVPh7d4jJ1z7/VEASM6fdbwhLUijl6CoQVIeOK8CSSf08SdQTqZWWyggdY3Aqe+UhxGSF Ga31pSDYDdneard4ojWdW8q6mhDhg5d+UpWWYqSFzKyNvJ68by9h8lgFSQGQRZndcMl7jSeqg2Oq aek= =Jhcv -----END PGP SIGNATURE-----