Re: problem with backup of changing file
"Petr Skoda" <[email protected]> Thu, 18 Aug 2022 22:10:47 +0200 (CEST)
| Newsgroups | gmane.comp.sysutils.backup.dar.support |
|---|---|
| Message-ID | <6Is.CLst.30V0dz55Xy}.1Y}[email protected]> |
---------- Původní e-mail ---------- Od: Denis Corbin <[email protected]> Komu: [email protected] Datum: 17. 8. 2022 18:24:51 Předmět: Re: [Dar-support] problem with backup of changing file "Hi Petr, Yes you can disable this feature with the '--retry-on-change 0' option. " Thank you ! - This really works "What you underline about tar is that is does not take care of modified files at the time they were backed up. Thus, you can end having corrupted files in a backup, if for example the file has some coherent structure at application level and this application modifies it near the beginning and near the end in coherent manner, frequently enough for it occurs more than once during the time required to read the whole file. During the backup process, if you simply read sequentially the file to backup, you will end with an incoherent file where the beginning is not coherent with the end of file. I would rather suggest --- if possible in regard to the service they address in production --- to pause the docker containers during the backup." Yes - this is a nice idea - using the hooks seems to be a good trick. Thanks for suggestion. However for some cases I want simple backup the server as it is and I do not know what specific packages are installing some special files disk handlers etc .... I Could in principle ignore just the known special files but I may not know what all is there. " To minimize the duration of the pause, you can rely on the --backup-hook-include, --backup-hook-exclude and --backup-hook-execute options of dar, that can run a script or command to pause containers when the backup process enters the directory /data/docker/devicemapper/devicemapper and then can call a second time (with slightly different arguments) when the backup exits this directory in order to unpause those containers. Doing this way, you could keep the retry-on-change feature active and thus be sure your "data" file is saved properly, which means that your containers will be able to restart from restored backup without this risk of failure. " yes it would be nice to be sure that all is on tape . However IMHO you may never be sure that all is there. Anyway thanks for quick reply " My 2 cents Denis Le 17/08/2022 à 17:45, Petr Skoda a écrit : > Hi Denis and all Dar lovers. > > I have faced a serious problem with backup of my /data directory. I am > not able to overcome the problem. > I am using pipe over nc - > dar -c - -R /data |nc lto 5000 > > machine lto reads > nc -l -p 5000|mbuffer -P 80 -m 1G > betelgeuse-data.1.dar > > I am using mbuffer over screen as I can always check the amount of > transfered data. > I do not think the porblem is here - probably the dar -c itself would > break as well > > after writting 139GB (shown by mbuffer) and looking at size of file > betelgeuse-data.1.dar > everything stops with message > > WARNING! File modified while reading it for backup. No more retry for that > file to not exceed the wasted byte limit. File is > /data/docker/devicemapper/devicemapper/data > > And the enter will not help to continue ... > > The problem is the docker devicemapper/data as it is a kind of a block > file specially handled by docker. But for OS it should be just another > file (the tar goes over it smoothly). > It is about 100GB but does not change size - only the date is updated > after ls -la it is current. > root@betelgeuse:devicemapper# ls -la data > -rw------- 1 root root 107374182400 Aug 17 17:42 data > > Is there some option how I can tell the dar to write what is available > and continue ? > > Now it stops and does not react .. No data are flowing through the nc . > > Thanks a lot > Petr Skoda > > > "