Backup – Fix ‘No Space Left’ Error When Backup Fails

backupdeja-dup

So I have a backup partition set aside on my 100GB HDD (old computer) of about 30 GB. I have some files that I want both Windows and Ubuntu to access (a NTFS partition) as well as the backup directory for Ubuntu.

However, when it goes to automatically backup it says that there is no space left. I have my backup settings set to this:

Backup Screenshot 1
Backup Screenshot 2

and it says that old backups will be kept until backup location is low on space. Why isn't it deleting old backups if it doesn't have enough space? Is it too low in the backup directory (again, delete old backups) or is it a problem with my /tmp or ~/.cache?

I looked at this question: Why does Déjà Dup say there is no space left?, but that didn't help any. AFAIK my tmp folder and my .cache folder aren't too large:

tmp folder specs .cache folder specs

EDIT: (11/18/2013)

Added results from command (duplicity remove-all-but-n-full 1 file:///media/nate/Backup/Backup --force):

Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20130901T193629Z.sigtar.gz to local cache.
Copying duplicity-full.20130901T193629Z.manifest to local cache.
Copying duplicity-inc.20130901T193629Z.to.20130905T184555Z.manifest to local cache.
Copying duplicity-inc.20130905T184555Z.to.20130912T120237Z.manifest to local cache.
Copying duplicity-inc.20130912T120237Z.to.20130919T173913Z.manifest to local cache.
Copying duplicity-inc.20130919T173913Z.to.20130926T110023Z.manifest to local cache.
Copying duplicity-inc.20130926T110023Z.to.20131003T111040Z.manifest to local cache.
Copying duplicity-inc.20131003T111040Z.to.20131010T112231Z.manifest to local cache.
Copying duplicity-inc.20131010T112231Z.to.20131019T172556Z.manifest to local cache.
Copying duplicity-inc.20131019T172556Z.to.20131024T120102Z.manifest to local cache.
Copying duplicity-new-signatures.20130901T193629Z.to.20130905T184555Z.sigtar.gz to local cache.
Copying duplicity-new-signatures.20130905T184555Z.to.20130912T120237Z.sigtar.gz to local cache.
Copying duplicity-new-signatures.20130912T120237Z.to.20130919T173913Z.sigtar.gz to local cache.
Copying duplicity-new-signatures.20130919T173913Z.to.20130926T110023Z.sigtar.gz to local cache.
Copying duplicity-new-signatures.20130926T110023Z.to.20131003T111040Z.sigtar.gz to local cache.
Copying duplicity-new-signatures.20131003T111040Z.to.20131010T112231Z.sigtar.gz to local cache.
Copying duplicity-new-signatures.20131010T112231Z.to.20131019T172556Z.sigtar.gz to local cache.
Copying duplicity-new-signatures.20131019T172556Z.to.20131024T120102Z.sigtar.gz to local cache.
Last full backup date: Sun Sep  1 15:36:29 2013
No old backup sets found, nothing deleted.

EDIT: (11/19/2013)

Ran duplicity cleanup file:///media/nate/Backup/Backup --force

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Sun Sep  1 15:36:29 2013
GnuPG passphrase: 
No extraneous files found, nothing deleted in cleanup.

Best Answer

Follow these steps to free up as much space as possible while keeping the latest backup:


Delete old backups through duplicity

You could try deleting old backup files manually.

For deleting all but the last full backup, open a terminal and run this:

duplicity remove-all-but-n-full 1 file:///media/nate/Backup/ --force

Delete files from failed backup sessions

If there is still no backup space, this might help (it deletes files from failed backup sessions):

duplicity cleanup file:///media/nate/Backup/ --force

Still no space

But for your case, I suppose that the backup partition is just full.

  • There is one full backup (from 2013-09-01), and
  • many increments (until 2013-10-19).

This means, that Duplicity/Ubuntu Backup won't delete any files as that would destroy the latest backup.

So for now, you will need to find backup space somewhere else and run a new backup. Or, you delete the current backup by hand and run a new backup immediately afterwards. But keep in mind, that you won't have any backup until the new backup is finished successfully.

Related Question