After three rysnc backup runs the backup,partition has filled.
This is a bit of a surprise

The root partition is 22G

/dev/nvme0n1p2 22G 17G 4.5G 79% /

The backup partition is 20G

/dev/nvme0n1p5 20G 20G 0 100% /bu

That was fast. It cant all be logs and I don't get any mail

The difference in partition size is only 3G so I suppose it could
overflow rapidly. I must find out, overflow with what?

It must be another weekend coming on :-)

regards

--
faeychild
Running plasmashell 5.15.4 on 5.4.2-desktop-1.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sun, 22 Dec 2019 08:24:38 +1100, faeychild wrote:

After three rysnc backup runs the backup,partition has filled.
This is a bit of a surprise

The root partition is 22G

/dev/nvme0n1p2 22G 17G 4.5G 79% /

The backup partition is 20G

/dev/nvme0n1p5 20G 20G 0 100% /bu

That was fast. It cant all be logs and I don't get any mail

Yeah, you think that 17G would fit in 20G. My best guess is 5% of 20G
plus 17G does not fit in 20G.

The difference in partition size is only 3G so I suppose it could
overflow rapidly. I must find out, overflow with what?

I know the journal can eat up a lot of space. Go ahead and look
ls -Alh

I can recommend that the backup partition should be the same size or
larger.

You can also waste space by not reducing the amount of reserved space.
When you create/format a partition, 5% is set aside as reserved space.

Go ahead and reduce your /bu reserved space. As root
tune2fs -m 0.01 /dev/nvme0n1p5

My other guess is your rsync arguments does not have --delete

If I am going to back up my install, I run my new_boot_log script which
will delete/empty log files and reboot.

Snippet from my new_journal script

_log_dir=/var/log/journal/$(cat /etc/machine-id)
if [ -e $_log_dir ] ; then
echo "Wiping journal logs"
journalctl --rotate
journalctl --vacuum-time=1s
sleep 2
rm --force $_log_dir/user-*.journal
rm --force $_log_dir/*@*
fi


--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 21 Dec 2019 16:12:02 -0600, Bit Twister wrote:

I know the journal can eat up a lot of space. Go ahead and look
ls -Alh

Sorry,

Probably would not hurt to give you the journal location.

ls -Alh /var/log/journal/$(cat /etc/machine-id)

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 21.12.2019 at 16:14, Bit Twister scribbled:

On Sat, 21 Dec 2019 16:12:02 -0600, Bit Twister wrote:

I know the journal can eat up a lot of space. Go ahead and look
ls -Alh

Sorry,

Probably would not hurt to give you the journal location.

ls -Alh /var/log/journal/$(cat /etc/machine-id)

One can configure how much space it may claim, though.


--
With respect,
= Aragorn =


--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Strider (2:250/1@fidonet)

On 2019-12-21, faeychild <faeychild@nomail.afraid.org> wrote:

After three rysnc backup runs the backup,partition has filled.
This is a bit of a surprise

The root partition is 22G

/dev/nvme0n1p2 22G 17G 4.5G 79% /

The backup partition is 20G

/dev/nvme0n1p5 20G 20G 0 100% /bu

That was fast. It cant all be logs and I don't get any mail

It is impossible to fit 23GB into 20GB.

It might for 17GB, but it is quite possible that there is a large number changes from one day to next.
I am not sure what you mean by "three rsync backups" 3*17GB= 52GB.

If you mean you have only one backup and you keep it up to date with
rsync, then it should only ned 17GB. If it is some sort of sequential
backup (eg rsnapshot) then find out what is changing each day.


You should make more liberal use of --exclude
to exclude lot of stuff that does not really need backing up (/tmp,
/var/tmp, ~user/tmp,....)

The difference in partition size is only 3G so I suppose it could
overflow rapidly. I must find out, overflow with what?

It must be another weekend coming on :-)

regards

--
faeychild
Running plasmashell 5.15.4 on 5.4.2-desktop-1.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sun, 22 Dec 2019 08:24:38 +1100, faeychild wrote:

After three rysnc backup runs the backup,partition has filled.
This is a bit of a surprise

The root partition is 22G

/dev/nvme0n1p2 22G 17G 4.5G 79% /

Looking like / is getting a bit snug.

Think about your next Release update. I like pulling down all update
rpms with --test. Then doing the update.

If you do not have the space for a full download you will have to
depend on the network not going down or getting a bad rpm download.

You might think about moving some of the directories to /dev/sda.

I assume you have not reduced the reserved blocks on sda so you are
wasting 5% of /video space.

If I was you, mageia_bu/, boot_iso, and mageia_6 would be on sda, and
install partition would be at least 30 gig.

If you decide to take my advice, you would rsync mageia_6 to sda, edit sdax/mageia_6/etc/fstab to use its new location, delete sdd mageia_6,
and run update-grub to pickup the new mageia_6 location.

If mageia_6/etc/fstab is using labels, you would change current mageia_6
label to old_mga6, then set new mga6 label as mageia_6, before doing
the rsync.



--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sun, 22 Dec 2019 08:24:38 +1100, faeychild wrote:

After three rysnc backup runs the backup,partition has filled. This is
a bit of a surprise

The root partition is 22G

/dev/nvme0n1p2 22G 17G 4.5G 79% /

The backup partition is 20G

/dev/nvme0n1p5 20G 20G 0 100% /bu

That was fast. It cant all be logs and I don't get any mail

The difference in partition size is only 3G so I suppose it could
overflow rapidly. I must find out, overflow with what?

It must be another weekend coming on :-)

Do you include --delete as an argument to rsync?

If not, any file copied to the destination location will remain there,
even if the original file has been deleted. That can increase the space required.

Separately, disk has become so cheap I use partition size at least twice
what I think I might need at max. That allows considerable tolerance for error.

SSD solid state drive is still expensive enough to pay attention to size,
but spinning rust is more inconvenience than cost, from my perspective.

Cheers!

jim b.

--
UNIX is not user-unfriendly, it merely expects users to be computer-
friendly.

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

Jim Beard wrote on 23/12/19 01:15:

On Sun, 22 Dec 2019 08:24:38 +1100, faeychild wrote:

After three rysnc backup runs the backup,partition has filled. This is
a bit of a surprise

The root partition is 22G

/dev/nvme0n1p2 22G 17G 4.5G 79% /

The backup partition is 20G

/dev/nvme0n1p5 20G 20G 0 100% /bu

That was fast. It cant all be logs and I don't get any mail

The difference in partition size is only 3G so I suppose it could
overflow rapidly. I must find out, overflow with what?

It must be another weekend coming on :-)

Do you include --delete as an argument to rsync?

Good point, Jim, which then beggars the question "When I update my
system via MCC, does the update process include this --delete argument??".

Or is the update process totally different to Rsyncing??

--
Daniel

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Mon, 23 Dec 2019 15:49:27 +1100, Daniel60 wrote:

Jim Beard wrote on 23/12/19 01:15:

Do you include --delete as an argument to rsync?

Good point, Jim, which then beggars the question "When I update my
system via MCC, does the update process include this --delete argument??".

Or is the update process totally different to Rsyncing??

Yes. Your MCC update, installs any new packages/rpms and removes the old rpm.

In this thread faeychild has booted a previous release (mga6) and is
running a script to mount partitions labeled mageia and mageia_bu then
runs rsync to sync mageia_bu with contents from mageia.

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

Bit Twister wrote on 23/12/19 16:01:

On Mon, 23 Dec 2019 15:49:27 +1100, Daniel60 wrote:

Jim Beard wrote on 23/12/19 01:15:

Do you include --delete as an argument to rsync?

Good point, Jim, which then beggars the question "When I update my
system via MCC, does the update process include this --delete argument??". >>
Or is the update process totally different to Rsyncing??

Yes. Your MCC update, installs any new packages/rpms and removes the old

rpm.

In this thread faeychild has booted a previous release (mga6) and is
running a script to mount partitions labeled mageia and mageia_bu then
runs rsync to sync mageia_bu with contents from mageia.

Thank you, BitTwister.

--
Daniel

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2019-12-23, Daniel60 <daniel47@eternal-september.org> wrote:

Jim Beard wrote on 23/12/19 01:15:

On Sun, 22 Dec 2019 08:24:38 +1100, faeychild wrote:

After three rysnc backup runs the backup,partition has filled. This is
a bit of a surprise

The root partition is 22G

/dev/nvme0n1p2 22G 17G 4.5G 79% /

The backup partition is 20G

/dev/nvme0n1p5 20G 20G 0 100% /bu

That was fast. It cant all be logs and I don't get any mail

The difference in partition size is only 3G so I suppose it could
overflow rapidly. I must find out, overflow with what?

It must be another weekend coming on :-)

Do you include --delete as an argument to rsync?

Good point, Jim, which then beggars the question "When I update my
system via MCC, does the update process include this --delete argument??".

yes.

Or is the update process totally different to Rsyncing??

Yes.
It uses urpmi, (which uses rpm) which cleans up after itself.
In general the names of the updated files are the same as the old ones,
but if there are some files which have had their names altered,(as done
by comparing the list of file names in the packages) the old one which
are not in the new one are removed. This only works if the name of the
package has not changedbetween old and new.



--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 22/12/19 9:12 am, Bit Twister wrote:

That was fast. It cant all be logs and I don't get any mail

Yeah, you think that 17G would fit in 20G. My best guess is 5% of 20G
plus 17G does not fit in 20G.

I assumed it would not blow out and 17G would fit. Stupid me!!

Originally I was going to exclude /home and /var from the backup because
of the incremental size increases in these partitions - config files,
mail, etc.. I thought that they were a small percentage of the actual
system files.

Rysnc doesn't remove redundant files. This probably why I've run over. --delete option will come in useful

Still, I have room and I can dink around with gparted

~]# lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT,PARTLABEL | grep -i nvme* nvme0n1 119.2G
├─nvme0n1p1 299M vfat /boot/EFI efi
├─nvme0n1p2 22.3G ext4 mageia / mageia
├─nvme0n1p3 10.6G swap swap [SWAP] swap
├─nvme0n1p4 12.2G ext4 tmp /tmp tmp
├─nvme0n1p5 20.4G ext4 mageia_bu mageia_bu
├─nvme0n1p6 2G ext4 boot_iso boot_iso
└─nvme0n1p7 24.9G ext4 mageia_6 mageia_6



~]# ls -Alh /var/log/journal/$(cat /etc/machine-id)
total 2.2G
-rw-r-----+ 1 root systemd-journal 16M Nov 28 23:46 'system@d0daa879970146c8ae1e2f5c28ab9b48-000000000022ba80-0005983d89e30493.jour nal'
-rw-r-----+ 1 root systemd-journal 16M Nov 30 16:49 'system@d0daa879970146c8ae1e2f5c28ab9b48-000000000024abef-00059867b0f1c668.jour nal'
-rw-r-----+ 1 root systemd-journal 16M Dec 2 07:56 'system@d0daa879970146c8ae1e2f5c28ab9b48-000000000026aed8-0005988a0d00f743.jour nal'
-rw-r-----+ 1 root systemd-journal 16M Dec 3 17:23 'system@d0daa879970146c8ae1e2f5c28ab9b48-000000000028b6a7-000598aac079cfca.jour nal'




These will surely add up


regards
--
faeychild
Running plasmashell 5.15.4 on 5.4.2-desktop-1.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 24/12/19 8:28 am, faeychild wrote:

Originally I was going to exclude /home and /var from the backup because
of the incremental size increases in these partitions - config files,
mail, etc.. I thought that they were a small percentage of the actual
system files.

Rysnc  doesn't remove redundant files. This probably why I've run over. --delete option will come in useful

I must re-read man rsync "delete" and "dry run" and give it a shot soon.

When eternal.september went down for some days, I chilled out a bit and stopped requiring everything to be fixed perfectly by yesterday.

sense of urgency cancelled.
Merry Christmas
--
faeychild
Running plasmashell 5.15.4 on 5.4.2-desktop-1.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)