Closing this report for series 0.10 because it has been fixed in latest
upstream version and won't fix in 0.10.
** Changed in: sbackup/0.10
Status: Confirmed => Won't Fix
** Changed in: sbackup (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you
** Also affects: sbackup
Importance: Undecided
Status: New
** Also affects: sbackup/0.10
Importance: Undecided
Status: New
** Also affects: sbackup/0.11
Importance: Undecided
Status: New
** Also affects: sbackup/trunk
Importance: Undecided
Status: New
**
Please check in your /etc/sbackup.conf file if you have really configured
SBackup to backup to a remote server, because if you have, then SBackups should
not do anything at all with /var/backup.
Could it be possible that you wrote the remote URL into the
simple-backup-config, but did not press t
Thank you for the feedback... my observation was as stated -- whatever
might have been in /tmp seemed insignificant compared to whatever was
going into /var/backup.
I believe I have several individual files that exceed the free space on
my root volume, so I suspect that the process(es) gzipping th
Yes, there are no provisions in SBackup against disk space overflow.
However if a backup is done to a remote location then the only thing
that is stored locally is a list of files to backuped which is stored in
/tmp, which usually is a RAM disk.
--
sbackup doesn't check for/prevent full disk
http
