duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] .Cache & duplicity collection-status


From: edgar . soldin
Subject: Re: [Duplicity-talk] .Cache & duplicity collection-status
Date: Mon, 12 Jul 2021 13:38:54 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1

On 12.07.2021 13:31, Сергей Цаболов wrote:
> Hello,
>
> 12.07.2021 13:31, edgar.soldin--- via Duplicity-talk пишет:
>> On 12.07.2021 10:33, Сергей Цаболов via Duplicity-talk wrote:
>>> Hello to all.
>>>
>>> I have one question.
>>>
>>> I setup duplicity and is work very well .
>>>
>>> I setup the cron job for backup  incremental with command :
>>>
>>> duplicity incremental --no-encryption  --exclude=/run --exclude=/proc 
>>> --exclude=/sys --exclude=/dev --exclude=/proc --exclude=/sys --exclude=/mnt 
>>> --exclude=/media --exclude=/tmp --exclude=/var/spool --exclude=/var/cache 
>>> --exclude=/var/tmp --exclude=/swap.img / file:///srv/duplicity/

did you notice that you doubled some exclusions above?

>>> I run is by root user.
>>>
>>> In /root/.cache/duplicity  is collect some files very big and my 
>>> root-file-system (/) is full 100%
>> that's the archive dir and needed for duplicity to work. man page [1] says
>> "
>> To save bandwidth, duplicity generates full signature sets and incremental 
>> signature sets. A full signature set is generated for each full backup, and 
>> an incremental one for each incremental backup. These start with 
>> duplicity-full-signatures and duplicity-new-signatures respectively. These 
>> signatures will be stored both locally and remotely. The remote signatures 
>> will be encrypted if encryption is enabled. The local signatures will not be 
>> encrypted and stored in the archive dir (see --archive-dir ).
>
> In the man [1] page I found that paragraph and now understand why is placed 
> the files there
>
>
>> "
>>
>> be aware that the mentioned argument above allows you to place the archive 
>> dir anywhere in case you run into space issues like you did.
>
> I found :
>
> The interaction between the --archive-dir and the --name options allows for 
> four possible combinations for the location of the archive dir:
>
>               1.     neither specified (default)
>                       ~/.cache/duplicity/hash-of-url
>
>               2.     --archive-dir=/arch, no --name
>                       /arch/hash-of-url
>
>               3.     no --archive-dir, --name=foo
>                       ~/.cache/duplicity/foo
>
>               4.     --archive-dir=/arch, --name=foo
>                       /arch/foo
>
> Which one is suitable for my case , for like now I moved the .cache/duplicity 
> in the storage and make Symlink to backup the /root/.cache/when backup moved 
> over nfs.

just point --archive-dir to wherever is enough space! e.g. 
--archive-dir=/mnt/bigspace/.duplicity-cache

>>
>> 1. what are the sizes of your partitions? maybe provide the output of 'df -h'
> Is one partition LVM 45G

the root partition?

>> 2. what's the size of your backup, how many files?
> I backup all files of the root file system path /  (with some exclude)

did you exclude the archive-dir from your backup? not sure i've seen it in your 
excludes.

>>
>>> Before I delete it, the command  duplicity collection-status  
>>> file:///srv/duplicity/ give Num volumes  duplicity-inc .
>>>
>>> After I delete the biggest  files from .cache the info about  Num volumes  
>>> duplicity-inc not show again only  the Full Num volumes
>> you are not supposed to manually edit that folder, although duplicity should 
>> survive and recreate missing data on the next run
> Ok,  right now I understand it, when I delete it :  duplicity 
> collection-status not show inc backup, but files stay in the place when all 
> backup.
>>
>>> How I can change the backup command to not collect sow big .cache files, 
>>> because if I run the duplicity cleanup --extra-clean --force $target  the 
>>> info about Num volumes of full and inc backups I will have ?
>> you can't change the size per se. if you have really big files to back up 
>> consider raising max-blocksize to lower the size of your sigtar files
> No, I not have many big files to backup, I backup full system, I understand I 
> can to include what I need to backup and situation changed (but is not so 
> simple in my case).
> I forget to write, files for inc grated  in cache for 2 days with cron job.

sorry. what do you mean by "files for inc grated  in cache for 2 days with cron 
job."?

..ede




reply via email to

[Prev in Thread] Current Thread [Next in Thread]