From: Benoit B. <ben...@gm...> - 2007-04-30 09:58:23
|
Hi, Someone could (or try) explain to me this strange thing??? I looked for disk space with unix command df : > df -h File system Size Occ Free %Occ Mount /dev/sda6 1,1T 135G 920G 13% /var But when I read "BackupPC : Host Summary. 47 full backups of total size 1384.71 Go (prior to pooling and compression) 72 inc backups of total size 65.73 Go (prior to pooling and compression) I don't unterstand what's happen, I must have a full device, but only 135Go seems to be occupated. Someone have an idea !!! -- Benoit BELY |
From: Johan E. <jo...@eh...> - 2007-04-30 11:44:48
|
Benoit BELY wrote: > Hi, > > Someone could (or try) explain to me this strange thing??? > > I looked for disk space with unix command df : > > df -h > File system Size Occ Free %Occ Mount > /dev/sda6 1,1T 135G 920G 13% /var > > But when I read "BackupPC : Host Summary. > > 47 full backups of total size 1384.71 Go (prior to pooling and compression) > 72 inc backups of total size 65.73 Go (prior to pooling and compression) > > I don't unterstand what's happen, I must have a full device, but only > 135Go seems to be occupated. > > Someone have an idea !!! > Hi! Those numbers are before pooling and compression, which leads us to these features: BackupPC uses compression, so if the data compresses well, you'll have less on your disk. It also uses pooling, so if many files are identical, they will be written only once on the disk, again reducing real disk usage. If you are unsure, try restoring and verifying the data. (You should always do that in a production system anyway!) Regards, Johan -- Johan Ehnberg Email: jo...@eh... GSM: +358503209688 WWW: http://www.ehnberg.net/johan/ |
From: Benoit B. <ben...@gm...> - 2007-04-30 11:59:52
|
2007/4/30, Johan Ehnberg <jo...@eh...>: > > Benoit BELY wrote: > > Hi, > > > > Someone could (or try) explain to me this strange thing??? > > > > I looked for disk space with unix command df : > > > df -h > > File system Size Occ Free %Occ Mount > > /dev/sda6 1,1T 135G 920G 13% /var > > > > But when I read "BackupPC : Host Summary. > > > > 47 full backups of total size 1384.71 Go (prior to pooling and > compression) > > 72 inc backups of total size 65.73 Go (prior to pooling and compression) > > > > I don't unterstand what's happen, I must have a full device, but only > > 135Go seems to be occupated. > > > > Someone have an idea !!! > > > > Hi! > > Those numbers are before pooling and compression, which leads us to > these features: > > BackupPC uses compression, so if the data compresses well, you'll have > less on your disk. > > It also uses pooling, so if many files are identical, they will be > written only once on the disk, again reducing real disk usage. > > If you are unsure, try restoring and verifying the data. (You should > always do that in a production system anyway!) > > Regards, > Johan > > -- > Johan Ehnberg > > Email: jo...@eh... > GSM: +358503209688 > WWW: http://www.ehnberg.net/johan/ > I'm surprising, the rate of compression and pool is around 10 1350 Go give 135 Go. Do you think it's normal rate??? I heard it should be around 5 or 6 but 10 seems to be large rate for me. Best regards -- Benoit BELY |
From: Johan E. <jo...@eh...> - 2007-04-30 12:10:38
|
Benoit BELY wrote: > > > 2007/4/30, Johan Ehnberg <jo...@eh... <mailto:jo...@eh...>>: > > Benoit BELY wrote: > > Hi, > > > > Someone could (or try) explain to me this strange thing??? > > > > I looked for disk space with unix command df : > > > df -h > > File system Size Occ Free %Occ Mount > > /dev/sda6 1,1T 135G 920G 13% /var > > > > But when I read "BackupPC : Host Summary. > > > > 47 full backups of total size 1384.71 Go (prior to pooling and > compression) > > 72 inc backups of total size 65.73 Go (prior to pooling and > compression) > > > > I don't unterstand what's happen, I must have a full device, but only > > 135Go seems to be occupated. > > > > Someone have an idea !!! > > > > Hi! > > Those numbers are before pooling and compression, which leads us to > these features: > > BackupPC uses compression, so if the data compresses well, you'll have > less on your disk. > > It also uses pooling, so if many files are identical, they will be > written only once on the disk, again reducing real disk usage. > > If you are unsure, try restoring and verifying the data. (You should > always do that in a production system anyway!) > > Regards, > Johan > > -- > Johan Ehnberg > > Email: jo...@eh... <mailto:jo...@eh...> > GSM: +358503209688 > WWW: http://www.ehnberg.net/johan/ > > > > I'm surprising, the rate of compression and pool is around 10 1350 Go > give 135 Go. > Do you think it's normal rate??? > I heard it should be around 5 or 6 but 10 seems to be large rate for me. > > Best regards > Well, if you keep a long trail of Full backups, these also may increase the historical load of backups, without actually increasing on disk. That's the same thing as "identical files" in my last answer. This is because of hard-linking in a filesystem. In other words: when you want the same file in two different locations (backups) BackupPC just tells the operating system to make them point at the same data on disk. Please note I'm new with BackupPC myself so unless you're going to verify the data with what I am saying, don't hold me responsable :). /johan |
From: Les M. <le...@fu...> - 2007-04-30 12:41:08
|
Benoit BELY wrote: > 2007/4/30, Johan Ehnberg <jo...@eh...>: >> >> Benoit BELY wrote: >> > Hi, >> > >> > Someone could (or try) explain to me this strange thing??? >> > >> > I looked for disk space with unix command df : >> > > df -h >> > File system Size Occ Free %Occ Mount >> > /dev/sda6 1,1T 135G 920G 13% /var >> > >> > But when I read "BackupPC : Host Summary. >> > >> > 47 full backups of total size 1384.71 Go (prior to pooling and >> compression) >> > 72 inc backups of total size 65.73 Go (prior to pooling and >> compression) >> > >> > I don't unterstand what's happen, I must have a full device, but only >> > 135Go seems to be occupated. >> > >> >> Those numbers are before pooling and compression, which leads us to >> these features: >> >> BackupPC uses compression, so if the data compresses well, you'll have >> less on your disk. >> >> It also uses pooling, so if many files are identical, they will be >> written only once on the disk, again reducing real disk usage. >> >> If you are unsure, try restoring and verifying the data. (You should >> always do that in a production system anyway!) >> > > I'm surprising, the rate of compression and pool is around 10 1350 Go give > 135 Go. > Do you think it's normal rate??? > I heard it should be around 5 or 6 but 10 seems to be large rate for me. 10 isn't unreasonable. The factors that can make it higher are files that are very compressible like text files or database files with a lot of blank records, and duplicate files, both from the same files on multiple machines and from having multiple full runs of the same machine in the archive. -- Les Mikesell les...@gm... |
From: Carl W. S. <ch...@re...> - 2007-04-30 12:16:17
|
On 04/30 01:59 , Benoit BELY wrote: > I'm surprising, the rate of compression and pool is around 10 1350 Go give > 135 Go. > Do you think it's normal rate??? > I heard it should be around 5 or 6 but 10 seems to be large rate for me. Depending on how compressible your data is; and how much duplication you have between servers, this is entirely possible. I have a server which has 3456.74GB of fulls and 88.93GB incrementals, compressed and pooled down to 188GB. That one is kind of a corner case; much of that data is mail backups, or HTML, or databases; and some fairly long-term backups are being kept (lots of 'copies' of the data in backuppc). It does however demonstrate that the figure is quite possible to achieve. -- Carl Soderstrom Systems Administrator Real-Time Enterprises www.real-time.com |
From: Benoit B. <ben...@gm...> - 2007-04-30 13:03:10
|
Hi, I am dummy.... I just understand why BackupPc use hard link. :-( Sorry and many thanks, I will buy a brain. And so I backup with one full per week until 10 month on 6 host, I have 8 full per host, I found the rate of 10 So it's all right Best regards -- Benoit BELY |