restore/revert produces only empty folders

Asked by Julien

Hello,

I have read https://answers.launchpad.net/sbackup/+question/130045 and I have the same problem but the provided solution is not working for me. Whatever button I click (revert/restore/revert to/ restore to), I only get empty folders with eventually empty sub-folders. If I do the same with a single file, the file is correctly restored. I can see in the .tar.gz file that my folders should not be empty.

I have french version running 0.11.3 on Ubuntu Maverick.
I am trying to restore files as root (from Applications->Outils Systemes Ubuntu main menu)

UPDATE:
This is not a question, it's confirmed as a bug in version 0.11.3, fixed in 0.11.4. See https://bugs.launchpad.net/sbackup/+bug/709338

Question information

Language:
English Edit question
Status:
Invalid
For:
sbackup Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
tlaurion (thierry-laurion) said :
#1

Same here.

Files can be reverted one by one... but what if I want to revert a complete directory architecture?

Please help! I need to revert those tons of pictures placed in different backups! There is no way I can restore each one manually!!!

Revision history for this message
olyerickson (olyerickson) said :
#2

I have precisely the same problem. I'm trying to restore selected archived directory trees onto another machine; SBackup successfully restores the selected directory structures but not the files contained therein. I am able to restore individual files.

As Tiriz says, "there is no way I can restore each one manually!" Please tell us we're missing something?

Revision history for this message
Jean-Peer Lorenz (peer.loz) said :
#3

Hello,

thanks for using sbackup. I don't fully understand your problem. It is, of course, possible to restore directories and files from a snapshot! I've tried it 5 min ago in order to confirm that it does work ;-)

I'll explain it:

Given you have a set of snapshots: full one and several incremental one. Files are only stored when they have changed, i.e. the latest incremental snapshot will only contain modified and new files as well as the directory structure.

The graphical UI provides 4 buttons:

----------------------------------
| Restore | Restore as |
|---------------------------------|
| Revert | Revert as |
----------------------------------

As already explained in https://answers.launchpad.net/sbackup/+faq/1325 there is a different behaviour between Restore and Revert. Restore extracts files and directories contained in the *selected* snapshot. In contrast, Revert extracts files and directories from the selected snapshot *and* its predecessors in reverse order.

That is, if you select the latest incremental snapshot (lets say it only contains unmodified files) and click 'Restore' it will restore only empty folders. If you click on 'Revert' it will restore all files and directories in reverse order. Same holds for 'restore as' and 'revert as'.

HTH.

Revision history for this message
olyerickson (olyerickson) said :
#4

Jean-Peer, thanks for your quick response!

In my case I only make (nightly) full backups, so if I understand what you're saying there should be no real difference. In any case, doing "Restore As..." and "Revert As..." achieved the same result --- only empty folders.

Maybe I'm missing something; here's what I've been trying to do:

* Mount backup drive on second system
* Use SBackup config to ensure SBackup "sees" the drive
* Use SBackup restore to "Revert As..." a full snapshot of e.g. my "/home" to a directory on the second system e.g. "/home/lifeboat"

At this point I see only folders... I can then select and revert individual files in the tree, but that gets really old for thousands of files :(

Revision history for this message
Julien (jcanivet) said :
#5

Hello Jean-Peer,

In my case, the backup I am trying to restore (/revet) is also a full backup. I understand your remarks about incremental backups : it only contains different files from the last full backup and in this case, a restore action restores effectivly only the files really contained in the archive.

This is not our case here : I want to restore from a full backup and not an incremental one. As I suppose that I (and the other people here) am in a special case, I would like to give you more information but I dont know how : is there a debug/hidden mode like a verbose one ? maybe we are using external programms (like 'find' or 'ls' bins) to sbackup which make that the list of files contain only empty folders ? How can I provide more information to you ?

Revision history for this message
Jean-Peer Lorenz (peer.loz) said :
#6

Hello Julien,

> is there a debug/hidden mode like a verbose one ?
You can enable 'debug' output level within the configuration gui on a per-profile basis. This will print a lot of helpful information into the logfile.

How to you invoke sbackup? Could you describe the structure of your file tree you're storing? I really want to help! It's working perfectly for me...so, I've currently no clue. Did you specified a kind of test profile containing only a small set of files and directories? Does such test case work as expected.

I'm looking forward to your outcomes, logs...Thanks.

Revision history for this message
Julien (jcanivet) said :
#7

I have enabled the debug output in the configuration gui.

I invoke sbackup from the Application menu in Ubuntu Maverick (french translation).

My tar.gz file is as follows :
/etc
/home
/usr/local
/var

If I try to restore my /home/julien/.thunderbird folder (containing one folder and three files), only the folder tree is restored but there is no file. I obtained the following log running with "RestoreAs" button.
****************************************************************************************************************************************************

SBackup 'Profil par défaut' Logger

==============

2011-01-27 17:39:12,752 - INFO in ConfigManager.__create_logger(750): Le journal pour [Profil par défaut] sera écrit dans '/var/log/sbackup/sbackup.2011-01-27_17.39.12.751034.log'.
2011-01-27 17:39:12,754 - DEBUG in ConfigManager.validateConfigFileOpts(799): Validating config file.
2011-01-27 17:39:12,755 - INFO in ConfigManager.__init__(331): Les réglages du profil sont lus à partir du fichier '/etc/sbackup.conf'.
2011-01-27 17:39:12,757 - DEBUG in pathparse.set_and_parse_uri(215): UriParser:
Display name: /media/160GB/sauvegardes
URI scheme: file
eff. scheme: file
Hostname: ``
Path: `/media/160GB/sauvegardes`
Port: None
Username: `None`
Password: `None`
2011-01-27 17:39:13,654 - DEBUG in pathparse.set_and_parse_uri(215): UriParser:
Display name: /media/160GB/sauvegardes
URI scheme: file
eff. scheme: file
Hostname: ``
Path: `/media/160GB/sauvegardes`
Port: None
Username: `None`
Password: `None`
2011-01-27 17:39:13,658 - DEBUG in _gio_fam.set_initialize_callback(62): set_initialize_callback: <bound method SBRestoreGTK.__set_destination_done_cb of <sbackup.ui.restoregui.SBRestoreGTK object at 0xa44a90c>>
2011-01-27 17:39:13,658 - INFO in _gio_fam.initialize(100): Initializing GIO File Access Manager.
2011-01-27 17:39:13,659 - DEBUG in pathparse.query_mount_uri(252): get_mount_uri: file:///media/160GB/sauvegardes
2011-01-27 17:39:13,661 - DEBUG in _gio_utils.mount(253): Mount path: file:///media/160GB/sauvegardes
2011-01-27 17:39:13,684 - DEBUG in _gio_utils._is_local(213): Given path is local
2011-01-27 17:39:13,692 - DEBUG in _gio_utils.mount(258): Mounting local path is not required - calling additional callback
2011-01-27 17:39:13,692 - DEBUG in _gio_fam._mount_cb(153): Calling additional callback in gio_fam._mount_cb: <bound method SBRestoreGTK.__set_destination_done_cb of <sbackup.ui.restoregui.SBRestoreGTK object at 0xa44a90c>>
2011-01-27 17:39:14,059 - DEBUG in pathparse.query_mount_uri(252): get_mount_uri: file:///media/160GB/sauvegardes
2011-01-27 17:39:14,061 - DEBUG in pathparse.query_mount_uri(252): get_mount_uri: file:///media/160GB/sauvegardes
2011-01-27 17:42:18,217 - DEBUG in RestoreManager.restoreAs(76): Restore as
 snapshot: `2010-12-13_11.43.10.731121.moines.ful`
 file (path in snapshot): `/home/julien/.thunderbird`
 restore target: `/home/julien/zzz_test_restauration_home_julien`
2011-01-27 17:42:23,288 - DEBUG in pathparse.query_mount_uri(252): get_mount_uri: file:///media/160GB/sauvegardes
2011-01-27 17:42:23,290 - DEBUG in _gio_utils.get_eff_path(757): get effective path for URI: `file:///media/160GB/sauvegardes`
2011-01-27 17:42:23,292 - DEBUG in _gio_utils.get_eff_path(760): Effective path: `/media/160GB/sauvegardes`
2011-01-27 17:42:23,292 - DEBUG in _gio_fam.get_eff_fullpath(178): Effective path: `/media/160GB/sauvegardes`
2011-01-27 17:42:23,293 - DEBUG in _gio_fam.get_eff_fullpath(179): Base path: `2010-12-13_11.43.10.731121.moines.ful/files.tar.gz`
2011-01-27 17:42:23,294 - DEBUG in RestoreManager.restoreAs(89): eff. local path to archive: /media/160GB/sauvegardes/2010-12-13_11.43.10.731121.moines.ful/files.tar.gz
2011-01-27 17:42:23,295 - DEBUG in RestoreManager.restoreAs(97): Restore target is given and exists
2011-01-27 17:42:23,295 - DEBUG in RestoreManager.restoreAs(99): Restore target is a directory (i.e. we extract into a directory)
2011-01-27 17:42:23,296 - DEBUG in RestoreManager.restoreAs(103): Restore tempdir: `/home/julien/zzz_test_restauration_home_julien/sbackup-restore_mykZJN`
2011-01-27 17:42:23,297 - DEBUG in tar.extract(92): input param `sourcear`: file:///media/160GB/sauvegardes/2010-12-13_11.43.10.731121.moines.ful/files.tar.gz
2011-01-27 17:42:23,299 - DEBUG in tar.extract(93): input param `eff_local_sourcear`: /media/160GB/sauvegardes/2010-12-13_11.43.10.731121.moines.ful/files.tar.gz
2011-01-27 17:42:23,301 - DEBUG in tar.extract(101): Archive type: gzip
2011-01-27 17:42:23,303 - DEBUG in tar.launch_sync(625): Lauching: /bin/tar -xp --gzip --ignore-failed-read --occurrence=1 --backup=existing --totals --same-owner --directory=/home/julien/zzz_test_restauration_home_julien/sbackup-restore_mykZJN --suffix=.before_restore_2011-01-27_17.42.23.294921 --file=/media/160GB/sauvegardes/2010-12-13_11.43.10.731121.moines.ful/files.tar.gz home/julien/.thunderbird
2011-01-27 17:42:23,370 - DEBUG in tar.launch_sync(644): Subprocess created
2011-01-27 17:42:23,476 - DEBUG in tar.__finish_tar(502): Exit code: 0
2011-01-27 17:42:23,477 - DEBUG in tar.__finish_tar(503): Standard out:
2011-01-27 17:42:23,477 - DEBUG in tar.__finish_tar(504): Error out: Total bytes read: 4884480 (4.7MiB, 64MiB/s)

2011-01-27 17:42:23,478 - INFO in tar.__finish_tar(522): TAR returned a message: Total bytes read: 4884480 (4.7MiB, 64MiB/s)
2011-01-27 17:42:23,479 - INFO in tar.__finish_tar(527): TAR has been finished successfully.
2011-01-27 17:42:23,480 - DEBUG in RestoreManager.restoreAs(111): File in restore target: `/home/julien/zzz_test_restauration_home_julien/.thunderbird`
2011-01-27 17:42:23,480 - DEBUG in RestoreManager.restoreAs(112): File in restore tempdir: `/home/julien/zzz_test_restauration_home_julien/sbackup-restore_mykZJN/home/julien/.thunderbird`
2011-01-27 17:52:53,569 - DEBUG in _gio_fam.set_terminate_callback(66): set_terminate_callback: <bound method SBRestoreGTK._term_fam_done_cb of <sbackup.ui.restoregui.SBRestoreGTK object at 0xa44a90c>>
2011-01-27 17:52:53,571 - INFO in _gio_fam.terminate(114): Terminating GIO File Access Manager.
2011-01-27 17:52:53,571 - DEBUG in pathparse.query_mount_uri(252): get_mount_uri: file:///media/160GB/sauvegardes
2011-01-27 17:52:53,571 - DEBUG in _gio_utils.umount(269): Umount path: file:///media/160GB/sauvegardes
2011-01-27 17:52:53,572 - DEBUG in _gio_utils._is_local(213): Given path is local
2011-01-27 17:52:53,572 - DEBUG in _gio_utils.umount(274): Unmounting local path is not required - calling additional callback
2011-01-27 17:52:53,572 - DEBUG in _gio_fam._umount_cb(165): Calling additional callback in gio_fam: <bound method SBRestoreGTK._term_fam_done_cb of <sbackup.ui.restoregui.SBRestoreGTK object at 0xa44a90c>>

***********************************************************************************************************************
If I launch the following command by myself in a terminal

/bin/tar -xp --gzip --ignore-failed-read --occurrence=1 --backup=existing --totals --same-owner --directory=/home/julien/zzz_test_restauration_home_julien/sbackup-restore_mykZJN --suffix=.before_restore_2011-01-27_17.42.23.294921 --file=/media/160GB/sauvegardes/2010-12-13_11.43.10.731121.moines.ful/files.tar.gz home/julien/.thunderbird

the result is the same : the folder tree is there but there is no file...

/bin/tar --version
tar (GNU tar) 1.23

It seems the problem comes from this command

Revision history for this message
Jean-Peer Lorenz (peer.loz) said :
#8

I've digged into it and found that your issue is a bug. The problem stems from tar's commandline option '--occurrence' which behaves inconsistently. It does work if a top-level folder is being extracted but does not work for other directories. Unfortunately, pre-release test didn't cover such cases. Sorry for any trouble. I've filed a bug https://bugs.launchpad.net/sbackup/+bug/709338 and will release a fix ASAP.

Thanks to all for choosing sbackup and helping to make it better.

Revision history for this message
Jean-Peer Lorenz (peer.loz) said :
#9

Changing status to 'Invalid' because this issue is actually a bug. Please refer to the linked bug report from now.