subject:"\\\\\\\[qubes\\\\\\\-users\\\\\\\] backup"

[qubes-users] Backup to SMB mounted NAS in AppVM

2021-04-01 Thread Beto HydroxyButyrate


Last night I tried to run QubesBackup, selecting an AppVM as the target, 
and then selecting the SMB-mounted (r/w) folder. 
The backup process started, and the progress bar presented a small sliver 
of blue on the left, but was 0%.  Nothing was ever written to the target.  
No errors were ever suggested by the backup process.  Pretty much 0% CPU 
was being used in dom0.

After several hours, I closed the dom0 QubesManager window, which also 
closed the backup window, and tried re-running it directly as "Qubes 
Backup" from the menu.  It claimed I had a backup running.  Still nothing 
whatsoever written to SMB mounted folder.

Has anyone successfully written to SMB mounted share using backup?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/714a2077-ca37-4e32-a1d1-65a9f55aeb57n%40googlegroups.com.

Re: [qubes-users] Backup/Restore issue

2020-03-27 Thread Claudio Chinicz

Yep. When I first installed the apps on the template and afterwards shut it off 
I saw the apps in the AppVM.

The issue happened when I've restored. And, again, I did not reinstall the apps 
in the template, they were already there. The dnf install command resulted in 
no change but it somehow "reminded" Qubes they exist and so I could use the 
again as UI/windows.

Regards

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6d44d12a-9c99-4905-966e-cecdf6e5bf24%40googlegroups.com.

Re: [qubes-users] Backup/Restore issue

2020-03-27 Thread scurge1tl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



Claudio Chinicz:
> Hi,
>
> I've created an oathtool AppVM following instructions from here:
> https://www.qubes-os.org/doc/multifactor-authentication/
>
> On the Fedora-30-minimal template I've also installed Nautilus file
> manager and Gedit to easy my process of token creation.
>
> I tested it and it worked as designed. Then I want to test
> backup/recovery before I would rely on this to store my tokens.
>
> To my surprise, when I restored the OTP VM together with it's
> template the applications (file manager and text editor) did not
> show up as available applications.
>
> I had to open a terminal on the template and run again dnf install.
> Although they were not installed again (because they were present
> when I backed up), after running dnf install Qubes "remembered"
> they were there as if were notified just then.
>
> Did I miss something when I backed up? Or is this behaviour
> expected?
>
> Thanks
>

Are you sure you installed the oathtool and other apps in the
Fedora-30 template and not in the AppVM?

Once you install the packages in the Fedora-30 template, shutdown the
template. Once the template is switched off, start the AppVM based on
Fedora-30 and you should see the packages available (in all Fedora-30
AppVMs based on that template).

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEExlmPb5HoPUTt+CQT44JZDAWK6UwFAl5972JfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2
NTk4RjZGOTFFODNENDRFREY4MjQxM0UzODI1OTBDMDU4QUU5NEMACgkQ44JZDAWK
6Uwriw//TMeDqlPrldYqR/QJa023S19h3LQy0seMqKToFR++YKMJAPg4PP917hJd
Ar468AzKTLcP4+UmJd6RXvzMBrMdgJD/NBOXap2mgFUrMrG7CICRSzsJ+hSS8Ze4
+owUQXIWNiTbiNlMii0IBQhpOdRbWa0RG9ocsUabBDZi5IPs0w19MGfelRkHU94Z
JjoH3boRgPk2QhzVGh25e5uT2WzLnXSBJRt7IyNdvxJ62BZMdgVDWjKS5nYzoZ6+
swjPjsZyLxkIHeePseGcC1r9FDekIwOhib5Mkak2Dk/WCfNsR7vUpgJ6e/XgTxSH
LBC1ul41+eefJ+UWzYs2Xw9giwHCtK7pEWE+elnjoRRRhFNdv2asQogUxiVmYt9g
xMivKaNmjhQyV+YQd728mPT9ltnlJvYuJaHwdACeof92AiMt053PApFv5U8HhWMZ
JKW/gUymrNsdVpTv3q7+ZFxF3qOfwt3y5Op67dzZ98PHUrum6Rw8G0KtA9y+ZVK9
cxYsgwLfO+xlB36PM+T5notXPTWaa9plP/f0R1JeWsO+WOQMa7f1JFuAkn/gBEzX
VhjA1qoVoq7Ge0DHtqJsylyvdoxEq0vaazzrYh8Iori6KgSEp8Msq3b5wPbIQB7Q
cCvojwHqrWTBW0NCvoKVWpa4Uv4RSjXJJNwCREsYb8Oco90xYtQ=
=BWBq
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/389c65e9-22ef-15c4-dfa5-0c7c7f4a2ba6%40cock.li.


0xC1F4E83AF470A4ED.asc
Description: application/pgp-keys

[qubes-users] Backup/Restore issue

2020-03-27 Thread Claudio Chinicz

Hi,

I've created an oathtool AppVM following instructions from here: 
https://www.qubes-os.org/doc/multifactor-authentication/

On the Fedora-30-minimal template I've also installed Nautilus file manager and 
Gedit to easy my process of token creation.

I tested it and it worked as designed. Then I want to test backup/recovery 
before I would rely on this to store my tokens.

To my surprise, when I restored the OTP VM together with it's template the 
applications (file manager and text editor) did not show up as available 
applications.

I had to open a terminal on the template and run again dnf install. Although 
they were not installed again (because they were present when I backed up), 
after running dnf install Qubes "remembered" they were there as if were 
notified just then.

Did I miss something when I backed up? Or is this behaviour expected?

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d909ef1b-3668-46ae-b48c-2aba8550326d%40googlegroups.com.

Re: [qubes-users] Backup issues with external USB and ESATA devices

2019-12-29 Thread 'awokd' via qubes-users

Charles Peters:
> In late September I backed up qubes using a new WD Elements external
> drive.  At the time I don't think I had sys-usb installed.  Yesterday when
> I tried to do the backups I was unable to mount the WD Elements drive,
> another USB connected Toshiba hard drive, or the Toshiba drive connected
> with ESATA.  I can mount USB flash drives, but with a vfat filesystem it
> will not support the large multi GB backup file.
> 
> Booting Debian with the ESATA connected Toshiba drive I can mount the WD
> Elements drive without any problems.  However I haven't figured out how to
> mount the SSD with Qubes OS lvm to copy the backup files.
> 
> Does anyone have any suggestions?

Pass the external partition through to a VM with qvm-block, then mount
it from inside the VM.


-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/aab9ab93-d1a0-2d00-c576-a58886123409%40danwin1210.me.

[qubes-users] Backup issues with external USB and ESATA devices

2019-12-27 Thread Charles Peters

In late September I backed up qubes using a new WD Elements external
drive.  At the time I don't think I had sys-usb installed.  Yesterday when
I tried to do the backups I was unable to mount the WD Elements drive,
another USB connected Toshiba hard drive, or the Toshiba drive connected
with ESATA.  I can mount USB flash drives, but with a vfat filesystem it
will not support the large multi GB backup file.

Booting Debian with the ESATA connected Toshiba drive I can mount the WD
Elements drive without any problems.  However I haven't figured out how to
mount the SSD with Qubes OS lvm to copy the backup files.

Does anyone have any suggestions?


Thanks,
Chuck

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAMet1z4TpcPB8CMgBd%2B0iDyavRFheDPk3x6mKg_AxYx_qz3SYQ%40mail.gmail.com.

[qubes-users] Backup error file too large ?

2019-07-10 Thread Luc libaweb

Every backup test show "Error : Writing backup to VM X failed : cat:write 
error: File Too large. 

I put USB disk on VM and active de backup Qubes os. Then, I have this error.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f6f2b38c-561a-4c79-95dd-33de3acfb5ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup while VMs are running??

2019-05-28 Thread unman

On Mon, May 27, 2019 at 11:51:02PM -0700, Claudio Chinicz wrote:
> Hi All,
> 
> I make few backups because I fear doing backups while using my VMs, specially 
> Windows 10 and Linux Mint HVMs. So, I do it once in a while, when I have have 
> some free time and can spen not using the computer while it prepares the 
> backups, after having shut down the VMs.
> 
> All the discussion about updates breaking Qubes makes me wonder I should do 
> backups more often.
> 
> Is it possible to do backups of HVMs and VMs in general while using them? I'm 
> afraid I may have an issue when restoring.
> 
> Thanks in advance,
> Claudio
> 

If you backup a running qube with Qubes backup, it will backup the state before 
you
started it. May or may not be what you want.

You can use file backups to capture anything since qube started.

btrfs will let you snapshot running systems.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190528232916.4jmlhu4le4vl2u5x%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup while VMs are running??

2019-05-28 Thread Chris Laprise

On 5/28/19 2:51 AM, Claudio Chinicz wrote:

Hi All,

I make few backups because I fear doing backups while using my VMs, specially
Windows 10 and Linux Mint HVMs. So, I do it once in a while, when I have have
some free time and can spen not using the computer while it prepares the
backups, after having shut down the VMs.

All the discussion about updates breaking Qubes makes me wonder I should do
backups more often.

Is it possible to do backups of HVMs and VMs in general while using them? I'm
afraid I may have an issue when restoring.

If you installed Qubes with the disk/storage defaults, which uses LVM
snapshots – or if you manually set it to install with Btrfs – then its
safe to backup while VMs are running. The backup will simply use the
snapshot from the last time the VM was shut down.

OTOH, if you manually changed the Qubes install to use Ext4 filesystem,
there might be a problem in that case.

The disk usage widget in the system tray will tell you what kind of
storage system your Qubes is using; if you used the default LVM it will
say "lvm" with the usage stats to the right.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/af598aec-0a29-4f3c-65c2-2216bb16e88e%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Backup while VMs are running??

2019-05-28 Thread Claudio Chinicz

Hi All,

I make few backups because I fear doing backups while using my VMs, specially 
Windows 10 and Linux Mint HVMs. So, I do it once in a while, when I have have 
some free time and can spen not using the computer while it prepares the 
backups, after having shut down the VMs.

All the discussion about updates breaking Qubes makes me wonder I should do 
backups more often.

Is it possible to do backups of HVMs and VMs in general while using them? I'm 
afraid I may have an issue when restoring.

Thanks in advance,
Claudio

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/53d9215d-b552-424b-b62c-af8ff0a8312d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup Error: Warning: unrecognized data found in configuration files

2019-05-06 Thread 'awokd' via qubes-users


Eccentric Butterfly:


Speaking of which, is there really any security benefit in making sure the 
backup is not connected to a network? Provided the encryption password is 
secure. I don't think this was mentioned in the docs anywhere as something to 
consider so it's probably a bit excessive on my part. Of course, provided the 
password is long and secure.

Since all contents of all AppVMs you select pass through your Backup VM, 
it's a good idea in general to be cautious about attaching it to a 
network if you don't have to. Same with any other AppVM, really. 
Security benefit is that it makes it harder to exfiltrate data.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4c5c021a-8375-5e0a-0cc6-704cc6484e92%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup Error: Warning: unrecognized data found in configuration files

2019-05-06 Thread Eccentric Butterfly

On Monday, 6 May 2019 17:14:46 UTC+1, daniel  wrote:
> On Sun, 5 May 2019 20:24:07 +
> "'awokd' via qubes-users"  wrote:
> 
> > Eccentric Butterfly:
> > > When I go to backup my Qubes, the backup screen shows a red error
> > > at the bottom of the window saying "Warning: unrecognized data
> > > found in configuration files".  
> 
> I ran into this and it was innocuous.  Probably you have deleted a qube
> that you backed up the last time you ran backup.  The system remembers
> the choices you made in the last backup and sets them up as the
> defaults. So it knows it is supposed to backup a qube that isn't there
> anymore.  So it says it's confused.  You can follow awokd's advice
> (the file will be recreated when you run backup; it is where the
> previous-backup settings are stored).  Or you can just ignore the
> message and continue with your backup.  I'd delete the file, just in
> case something more serious is happening.
> 
> Best Wishes,
> Daniel
> 
> > /etc/qubes/backup/qubes-manager-backup.conf" in dom0 terminal. This
> > will delete the configuration you saved last time you ran backup.
> > 
> > > Why is this? Is there anything I need to do? Will this have any
> > > effect on my ability to backup and restore? 
> > Haven't seen it before so don't know if it would prevent backups or 
> > restores.
> >


Thanks for your reply guys. I think it's a mix of what both of you are saying.

When I backup qubes to a hard drive, I make sure the qube is not connected to a 
network. When I'm done, I usually delete the qube. Though in this case, it 
wasn't deleted (or I re-made the qube with the same name). but it also wasn't 
running.

When I saw the contents of that file, I realised the path in the 'BACKUP' qube 
was no longer valid as 1) the qube was not running and 2) the hard drive would 
not be mounted. Thus, I ran the qube and mounted it and the error was gone.

Thanks for your help, it was much appreciated!
Butterfly.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f1d22ab5-6296-47fb-8e7c-eb5fe6ed4243%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup Error: Warning: unrecognized data found in configuration files

2019-05-06 Thread Eccentric Butterfly

On Monday, 6 May 2019 22:35:55 UTC+1, Eccentric Butterfly  wrote:
> On Monday, 6 May 2019 17:14:46 UTC+1, daniel  wrote:
> > On Sun, 5 May 2019 20:24:07 +
> > "'awokd' via qubes-users"  wrote:
> > 
> > > Eccentric Butterfly:
> > > > When I go to backup my Qubes, the backup screen shows a red error
> > > > at the bottom of the window saying "Warning: unrecognized data
> > > > found in configuration files".  
> > 
> > I ran into this and it was innocuous.  Probably you have deleted a qube
> > that you backed up the last time you ran backup.  The system remembers
> > the choices you made in the last backup and sets them up as the
> > defaults. So it knows it is supposed to backup a qube that isn't there
> > anymore.  So it says it's confused.  You can follow awokd's advice
> > (the file will be recreated when you run backup; it is where the
> > previous-backup settings are stored).  Or you can just ignore the
> > message and continue with your backup.  I'd delete the file, just in
> > case something more serious is happening.
> > 
> > Best Wishes,
> > Daniel
> > 
> > > /etc/qubes/backup/qubes-manager-backup.conf" in dom0 terminal. This
> > > will delete the configuration you saved last time you ran backup.
> > > 
> > > > Why is this? Is there anything I need to do? Will this have any
> > > > effect on my ability to backup and restore? 
> > > Haven't seen it before so don't know if it would prevent backups or 
> > > restores.
> > >
> 
> 
> Thanks for your reply guys. I think it's a mix of what both of you are saying.
> 
> When I backup qubes to a hard drive, I make sure the qube is not connected to 
> a network. When I'm done, I usually delete the qube. Though in this case, it 
> wasn't deleted (or I re-made the qube with the same name). but it also wasn't 
> running.
> 
> When I saw the contents of that file, I realised the path in the 'BACKUP' 
> qube was no longer valid as 1) the qube was not running and 2) the hard drive 
> would not be mounted. Thus, I ran the qube and mounted it and the error was 
> gone.
> 
> Thanks for your help, it was much appreciated!
> Butterfly.

Speaking of which, is there really any security benefit in making sure the 
backup is not connected to a network? Provided the encryption password is 
secure. I don't think this was mentioned in the docs anywhere as something to 
consider so it's probably a bit excessive on my part. Of course, provided the 
password is long and secure.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/22534478-c0e4-4428-adcf-35baa15aa4ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup Error: Warning: unrecognized data found in configuration files

2019-05-06 Thread Daniel Allcock

On Sun, 5 May 2019 20:24:07 +
"'awokd' via qubes-users"  wrote:

> Eccentric Butterfly:
> > When I go to backup my Qubes, the backup screen shows a red error
> > at the bottom of the window saying "Warning: unrecognized data
> > found in configuration files".  

I ran into this and it was innocuous.  Probably you have deleted a qube
that you backed up the last time you ran backup.  The system remembers
the choices you made in the last backup and sets them up as the
defaults. So it knows it is supposed to backup a qube that isn't there
anymore.  So it says it's confused.  You can follow awokd's advice
(the file will be recreated when you run backup; it is where the
previous-backup settings are stored).  Or you can just ignore the
message and continue with your backup.  I'd delete the file, just in
case something more serious is happening.

Best Wishes,
Daniel

> /etc/qubes/backup/qubes-manager-backup.conf" in dom0 terminal. This
> will delete the configuration you saved last time you ran backup.
> 
> > Why is this? Is there anything I need to do? Will this have any
> > effect on my ability to backup and restore? 
> Haven't seen it before so don't know if it would prevent backups or 
> restores.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190506111437.6a563379%40allcock.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup Error: Warning: unrecognized data found in configuration files

2019-05-05 Thread 'awokd' via qubes-users


Eccentric Butterfly:

When I go to backup my Qubes, the backup screen shows a red error at the bottom of the 
window saying "Warning: unrecognized data found in configuration files".


Try closing backup, then "rm 
/etc/qubes/backup/qubes-manager-backup.conf" in dom0 terminal. This will 
delete the configuration you saved last time you ran backup.



Why is this? Is there anything I need to do? Will this have any effect on my 
ability to backup and restore?

Haven't seen it before so don't know if it would prevent backups or 
restores.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2d59434f-6304-3753-ab5a-509f2dbc7194%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Backup Error: Warning: unrecognized data found in configuration files

2019-05-05 Thread Eccentric Butterfly

When I go to backup my Qubes, the backup screen shows a red error at the bottom 
of the window saying "Warning: unrecognized data found in configuration files".

Why is this? Is there anything I need to do? Will this have any effect on my 
ability to backup and restore?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/aabae889-1b34-494d-b6fb-777c3ca5ec7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Backup Error: Warning: unrecognized data found in configuration files

2019-05-05 Thread Eccentric Butterfly

When I go to backup Qubes, the backup screen shows a red error at the bottom of 
the window saying "Warning: unrecognized data found in configuration files"

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5f7742b1-5a8a-49e7-8f30-b1c3dfdae324%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup with debian-10-minimal based sys-usb fails

2019-04-17 Thread Sven Semmler

On 4/15/19 6:25 PM, unman wrote:
> Why do you say this? Backup works fine with a buster qube. What is the
> exact problem that you have?

I apologize. The issue was between chair and keyboard. In Fedora
external drives are mounted under /run/media/user and in Debian under
/media/user ... sorry for wasting your time. I must have been very tired
last time I tried.

It all works now. Funny enough all of my qubes are based on modified
debian-minimal templates, which makes me very happy as there are no
unneeded packages installed. OCD granted. The only qube I have to run
with the full debian template is sys-usb. I'll keep searching what is
needed (natuilus and qubes-core-agent-nautilus alone are not enough). If
I figure it out, I will reply here.

Thank you!

/Sven

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f9e9494b-303f-0118-54af-226efb419181%40SvenSemmler.org.
For more options, visit https://groups.google.com/d/optout.

signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] backup with debian-10-minimal based sys-usb fails

2019-04-15 Thread unman

On Mon, Apr 15, 2019 at 04:23:25PM -0500, Sven Semmler wrote:
> On 4/5/19 12:52 AM, Sven Semmler wrote:
> >> You could install a file manager but then you're getting closer to
> >> the normal Debian template which is pretty minimal. If you are
> >> committed to minimal service qubes, CLI backup .
> > You convinced me. My intermediate solution will be to run sys-net and
> > sys-firewall as named disposable VMs based on a true minimal (not the
> > one I messed with, but the original minimal template plus the
> > qubes-core-* packets required for networking). And sys-usb as a named
> > disposable VM based on the plain debian template.
> 
> Actually with the normal debian template only restore works. Backup has
> the same issue even though the file manager and selection comes up. For
> the time being I have restored the fedora-29 minimal template just for
> sys-usb, but I'd love to find out what packages are required to make it
> work ... so I could use a debian based template for sys-usb.
> 

Why do you say this? Backup works fine with a buster qube. What is the
exact problem that you have?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190415232511.cn6dqipm2gwglb6r%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup with debian-10-minimal based sys-usb fails

2019-04-15 Thread Sven Semmler

On 4/5/19 12:52 AM, Sven Semmler wrote:
>> You could install a file manager but then you're getting closer to
>> the normal Debian template which is pretty minimal. If you are
>> committed to minimal service qubes, CLI backup .
> You convinced me. My intermediate solution will be to run sys-net and
> sys-firewall as named disposable VMs based on a true minimal (not the
> one I messed with, but the original minimal template plus the
> qubes-core-* packets required for networking). And sys-usb as a named
> disposable VM based on the plain debian template.

Actually with the normal debian template only restore works. Backup has
the same issue even though the file manager and selection comes up. For
the time being I have restored the fedora-29 minimal template just for
sys-usb, but I'd love to find out what packages are required to make it
work ... so I could use a debian based template for sys-usb.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e645edf3-cbc0-3087-b7b0-19a07f544a32%40SvenSemmler.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] backup with debian-10-minimal based sys-usb fails

2019-04-04 Thread Sven Semmler

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 3/31/19 9:36 AM, unman wrote:
> 1. The minimal template is minimal - it doenst have any GUI file 
> manager. When you click on the ... button it spawns a file manager
> in the backup qube. Since you dont have one installed it cant be 
> opened.

I neglected to mention that I did install nautilus for that very reason.


> You could install a file manager but then you're getting closer to
> the normal Debian template which is pretty minimal. If you are
> committed to minimal service qubes, CLI backup .

You convinced me. My intermediate solution will be to run sys-net and
sys-firewall as named disposable VMs based on a true minimal (not the
one I messed with, but the original minimal template plus the
qubes-core-* packets required for networking). And sys-usb as a named
disposable VM based on the plain debian template.

Soon though I will understand the CLI for backup and restore and
automate my backups using a shell script. Then sys-usb will be like
sys-net and sys-firewall already are.

Thank you for your help!

/Sven

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlym7RQACgkQ2m4We49U
H7bMpg//XeEzn1KGpgVWGK4MCekQ2RuJXNJItOsdnnGK4yxDHbPIEewdP4EIl+ZW
/+jwoTsWXHImpSJBaaFCWBayZwhOgyUaLVBT08GGd6P6hbNYBxiOG2qdrPrCEsds
XlVfwgfPTKIVVKn2poegzZ/762c/kPa5E1aL+nB+UqCzO05kuXoH720HpVcTmywW
ig6bOeuXlowOrLMXgUKsHaA111WmEfrbReVDDzf25xrZukPiFX7FhIKT3wQfGdSf
Z+wFvL+7CEvk4WBBR5PA2y8mx5BSXiYVOuR4zKPI9yXVhZnc5QkrB9lp3LljcIqA
TF6VfsYyAYYjg7rmEe7i72gzUf8eAbXvKXvZUzfJ3cblRUxAKIdUU/rCRUJS2QvX
5gR+y4XFG4ZXit3LNxqRmi0G1aL0haSvnGWhykeTK+q7Jclym9sInabuoKs+zme4
Tu2wg7Exkvx6kJ9+DRn1DhVyi1CPAJP6dXHsqnVhy6/xpSfulMPsqugW8EngcdsK
8xYKQfO2N1ddTI6qlljeE/PLDPPsgyPW0wk0/dHadOfFQ9FrdSYV1H3ZDxfRozEH
HjL8DmXuwpgEash748pb0KQgbEGRBorUGTRWVD6RtXgBpDu15ME0MwF7DYiYMC9V
FFWPHAin1hMI3jLC+TaPRnNlkC7CPXLmKCxpBHEY2jzj3YqhOew=
=ZgVG
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2680f942-0284-d929-9b51-01226087e07e%40SvenSemmler.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup with debian-10-minimal based sys-usb fails

2019-03-31 Thread Chris Laprise


On 3/31/19 10:36 AM, unman wrote:


I'm not convinced about Debian packages being more secure than rpm: they
are, of course nicer. :-)


To me, its a matter of Fedora packages being less secure than *everyone 
else*.



I'm a long standing Debian user with an antipathy to RedHat and Fedora.
The biggest drawback in using Debian packages in Qubes is that they are
configured on install, which requires some user intervention across
various qubes. Fedora doesnt do this, I think.


Shouldn't it be possible to run 'apt' in a mode where it accepts the 
default (not always 'yes') response?


The qubes-multi-update script already does this when run in unattended 
mode and I've never had a problem with it, even in highly customized 
Debian templates.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f3075d83-a02e-f49d-abc8-76ffc4bfed3d%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup with debian-10-minimal based sys-usb fails

2019-03-31 Thread unman

On Sun, Mar 31, 2019 at 01:10:14AM -0500, Sven Semmler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Very recently I migrated all my AppVMs to a debian-10 (buster)
> template, which itself was created by upgrading the debian-9 template.
> 
> Equally my sys-net, sys-usb and sys-firewall dispvms are based on a
> debian-10-minimal, which was upgraded from the debian-9-minimal. There
> was one little hick-up with the qubes-update-proxy (tinyproxy), but
> unman quickly pointed out what needed to be done.
> 
> Now I have only 2 things left that don't work as before:
> 
> 1) Currently I can't backup. I never tried the CLI way and will do so
> soon. Until now I always used the qubes manager. However, since my
> sys-usb is based on the minimal debian-10 template ... it doesn't work
> anymore. When I want to make a backup I simply get a message that the
> backup is not running. Also, in both cases (making and restoring
> backup) the dialog that lets me select target/source doesn't show up
> anymore after clicking the "..." button.
> 
> I searched qubes-users and qubes-issue and did install the
> qubes-core-admin-client in the template but that alone doesn't do the
> trick. What could my next step be? Which log file to check? Any idea
> what could be missing? (If I switch back to the fedora-minimal based
> sys-usb it works).
> 
> 2) When selecting what to backup I am used to see sys-net(0),
> sys-usb(0) and sys-firewall(0) and exclude them. They are of size zero
> as they are named disposable vms. However now I see both sys-net and
> sys-firewall having a size (~30 MB slowly increasing day by day !?!)
> But they are of class DispVM and are based on dvm-sys which in turn is
> based on the minimal debian template. What could be going on here?
> 
> Why am I doing this? ... over the last few months I have formed the
> impression that some of the more knowledgeable contributors on
> qubes-users (e.g. unman and tasket) prefer debian. And I do get
> annoyed be the super frequent updates of fedora. So I thought I'd try
> out to switch everything to debian in the hope that I would then have
> templates that can stay in use for many months if not years before I
> need to switch again (I went through fedora 24-29 since using qubes).
> Also another person with linux background said something about the
> debian package format being better and more secure against
> man-in-the-middle attacks (haven't researched that claim myself yet).
> 
> If anyone has information to confirm or disabuse me of the above
> impressions, I am all ears.
> 
> Thank you!
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlygWcYACgkQ2m4We49U
> H7ZhABAA4gEFBVqImM+Xr7yjHKqJ1NC+kJez7yBUSxxPfRPoZhzoFuRJxlsSrit4
> Bkglan0auyqDWQLaUjMwy3NWJQpxvBQuv/1HpQN1q3FuZoKw0giCT1ZkZ+FhvOwv
> UsjmyiXdOmPSCXeejDLAhuwX1ZmUEV1JuLxAnexswEMe1QZV1N8Qa1DwwFG5XoEw
> SXYLXKgZceTT/OQXh8CZhiKCAEKEOX38U86w0OXVdNH4oSPcoLy14MAXa0WlDukk
> 7QXeh4kPfsOx9hWxtQMKJ3Lyw4kxZoTvXFOGzUx94WyGRuuTQpru8CQJywAdM0Xe
> sTbOmxyQAeH5ABY9ZUsO/I4BTq34uSpLEFDirNQ7FnK+vcG2MwdjnSP7xdDR1Iom
> Hw4sRhvlnJzWxFuZVoT2F2dLKnNd833d6zy4xyiy2h0LkHETDyo4Oprp5uVDrJPk
> 1J43eZHBdHF+YjAREwC1/JPkfbGWOx1q5KpVE3TtQpOf82kLjJNWBqaERyEY1J/e
> QAAnRPbXI1LNUYazOkJ1Qv992gsyglHPDqdQtl+g8bKudRznvdoEr+kLyn1uduF9
> A7IUT1Ctk+NVyA7N9msjSCdzPiANCIdMddqL94zvpRuSaRTK7qRUN7z5fspt3XZb
> 3NPvTTh0hRinNh7c1rrzLdnJfb/0QDl9bX6touxhuOOdkYwAgAE=
> =Ujwj
> -END PGP SIGNATURE-
> 

1. The minimal template is minimal - it doenst have any GUI file
manager.
When you click on the ... button it spawns a file manager in the backup
qube. Since you dont have one installed it cant be opened.
You could install a file manager but then you're getting closer to the
normal Debian template which is pretty minimal.
If you are committed to minimal service qubes, CLI backup .

2. DisposableVMs will still have *some* size, as they differ from the
underlying template. When they are closed those differences will be
thrown away. (Just as you can download an iso in a disposableVM and see
the size balloon.)
I dont know what exactly is happening in your case - logs perhaps?

I'm not convinced about Debian packages being more secure than rpm: they
are, of course nicer. :-)
I'm a long standing Debian user with an antipathy to RedHat and Fedora.
The biggest drawback in using Debian packages in Qubes is that they are
configured on install, which requires some user intervention across
various qubes. Fedora doesnt do this, I think.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190331143618.o32x7fhqkof7xfxl%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] backup with debian-10-minimal based sys-usb fails

2019-03-31 Thread Sven Semmler

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Very recently I migrated all my AppVMs to a debian-10 (buster)
template, which itself was created by upgrading the debian-9 template.

Equally my sys-net, sys-usb and sys-firewall dispvms are based on a
debian-10-minimal, which was upgraded from the debian-9-minimal. There
was one little hick-up with the qubes-update-proxy (tinyproxy), but
unman quickly pointed out what needed to be done.

Now I have only 2 things left that don't work as before:

1) Currently I can't backup. I never tried the CLI way and will do so
soon. Until now I always used the qubes manager. However, since my
sys-usb is based on the minimal debian-10 template ... it doesn't work
anymore. When I want to make a backup I simply get a message that the
backup is not running. Also, in both cases (making and restoring
backup) the dialog that lets me select target/source doesn't show up
anymore after clicking the "..." button.

I searched qubes-users and qubes-issue and did install the
qubes-core-admin-client in the template but that alone doesn't do the
trick. What could my next step be? Which log file to check? Any idea
what could be missing? (If I switch back to the fedora-minimal based
sys-usb it works).

2) When selecting what to backup I am used to see sys-net(0),
sys-usb(0) and sys-firewall(0) and exclude them. They are of size zero
as they are named disposable vms. However now I see both sys-net and
sys-firewall having a size (~30 MB slowly increasing day by day !?!)
But they are of class DispVM and are based on dvm-sys which in turn is
based on the minimal debian template. What could be going on here?

Why am I doing this? ... over the last few months I have formed the
impression that some of the more knowledgeable contributors on
qubes-users (e.g. unman and tasket) prefer debian. And I do get
annoyed be the super frequent updates of fedora. So I thought I'd try
out to switch everything to debian in the hope that I would then have
templates that can stay in use for many months if not years before I
need to switch again (I went through fedora 24-29 since using qubes).
Also another person with linux background said something about the
debian package format being better and more secure against
man-in-the-middle attacks (haven't researched that claim myself yet).

If anyone has information to confirm or disabuse me of the above
impressions, I am all ears.

Thank you!

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlygWcYACgkQ2m4We49U
H7ZhABAA4gEFBVqImM+Xr7yjHKqJ1NC+kJez7yBUSxxPfRPoZhzoFuRJxlsSrit4
Bkglan0auyqDWQLaUjMwy3NWJQpxvBQuv/1HpQN1q3FuZoKw0giCT1ZkZ+FhvOwv
UsjmyiXdOmPSCXeejDLAhuwX1ZmUEV1JuLxAnexswEMe1QZV1N8Qa1DwwFG5XoEw
SXYLXKgZceTT/OQXh8CZhiKCAEKEOX38U86w0OXVdNH4oSPcoLy14MAXa0WlDukk
7QXeh4kPfsOx9hWxtQMKJ3Lyw4kxZoTvXFOGzUx94WyGRuuTQpru8CQJywAdM0Xe
sTbOmxyQAeH5ABY9ZUsO/I4BTq34uSpLEFDirNQ7FnK+vcG2MwdjnSP7xdDR1Iom
Hw4sRhvlnJzWxFuZVoT2F2dLKnNd833d6zy4xyiy2h0LkHETDyo4Oprp5uVDrJPk
1J43eZHBdHF+YjAREwC1/JPkfbGWOx1q5KpVE3TtQpOf82kLjJNWBqaERyEY1J/e
QAAnRPbXI1LNUYazOkJ1Qv992gsyglHPDqdQtl+g8bKudRznvdoEr+kLyn1uduF9
A7IUT1Ctk+NVyA7N9msjSCdzPiANCIdMddqL94zvpRuSaRTK7qRUN7z5fspt3XZb
3NPvTTh0hRinNh7c1rrzLdnJfb/0QDl9bX6touxhuOOdkYwAgAE=
=Ujwj
-END PGP SIGNATURE-

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/3b2d3725-d7de-41ac-c15c-cf6a48809763%40SvenSemmler.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup of files in a qube without networking to an internet service

2019-02-19 Thread unman

On Tue, Feb 19, 2019 at 03:41:23PM +, lik...@gmx.de wrote:
> Hi,
> 
> assume there are files stored in a qube without networking. Furthermore 
> assume there's a secured backup server located in the internet. This server 
> is only a storage of client-side (before data is sent over the wire) 
> encrypted files.  What options do you imagine to backup those files (skip the 
> client-side encryption) to the server?
> 
> I can imagine the following options:
> 1. enable temporary the network with firewall restricted to the server for  
> the (previously offline) qube
>  Advantage: no inter-vm copying of files.
>     Disadvantage: firewall rules must be setup correctly to avoid to bypass 
> any other traffic like icmp/dns etc. I can imaging a potential information 
> leakage due to enabling network access.
> 2. copy files temporary to another qube (dvm?) with a firewalled internet 
> connection
>     Advantage: files not being backed up can stay secured in the non-network 
> cube. Leakage of data is reduced in comparison to 1.
>     Disadvantage: can take time and needs additional disk ressources
> 
> I've learned that you should always find at least 3 options, otherwise you 
> haven't thought hard enough. Which options am I missing?
> 
> Which option would you prefer and why?
> 
> Best, Pete

3. Create encrypted (compressed) backup in offline qube.
qvm-copy backup to online disposableVM.
Copy encrypted file to backup server.

Advantage: All files secured in non-network qube.
Disadvantage: ???

Is inter-vm copying of files really an issue? Free space such an issue?
Using compressed backups should help mitigate this as a serious issue,
but that problem would extend to *all* your Qubes use.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190220004623.q5vg6vwzhg3r5fv6%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup of files in a qube without networking to an internet service

2019-02-19 Thread Chris Laprise

On 2/19/19 10:41 AM, lik...@gmx.de wrote:

Hi,

assume there are files stored in a qube without networking. Furthermore
assume there's a secured backup server located in the internet. This
server is only a storage of client-side (before data is sent over the
wire) encrypted files. What options do you imagine to backup those
files (skip the client-side encryption) to the server?

I can imagine the following options:
1. enable temporary the network with firewall restricted to the server
for the (previously offline) qube

Advantage: no inter-vm copying of files.
Disadvantage: firewall rules must be setup correctly to avoid to
bypass any other traffic like icmp/dns etc. I can imaging a potential
information leakage due to enabling network access.
2. copy files temporary to another qube (dvm?) with a firewalled
internet connection
Advantage: files not being backed up can stay secured in the
non-network cube. Leakage of data is reduced in comparison to 1.

Disadvantage: can take time and needs additional disk ressources

I've learned that you should always find at least 3 options, otherwise
you haven't thought hard enough. Which options am I missing?

Which option would you prefer and why?

Another disadvantage of #1 is that connecting the net to the source qube
exposes it to attack.

Had you thought about using qvm-backup? Also, I'm working on a fast
incremental backup tool that's suitable for Qubes:

https://github.com/tasket/sparsebak

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/cfdd9ce7-b95b-f26a-5cf9-19e0df29d70d%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] backup of files in a qube without networking to an internet service

2019-02-19 Thread liked2

Hi,

assume there are files stored in a qube without networking. Furthermore assume
there's a secured backup server located in the internet. This server is only a
storage of client-side (before data is sent over the wire) encrypted files.
What options do you imagine to backup those files (skip the client-side
encryption) to the server?

I can imagine the following options:
1. enable temporary the network with firewall restricted to the server for the
(previously offline) qube
Advantage: no inter-vm copying of files.
Disadvantage: firewall rules must be setup correctly to avoid to bypass any
other traffic like icmp/dns etc. I can imaging a potential information leakage
due to enabling network access.
2. copy files temporary to another qube (dvm?) with a firewalled internet
connection
Advantage: files not being backed up can stay secured in the non-network
cube. Leakage of data is reduced in comparison to 1.
Disadvantage: can take time and needs additional disk ressources

I've learned that you should always find at least 3 options, otherwise you
haven't thought hard enough. Which options am I missing?

Which option would you prefer and why?

Best, Pete

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/46bf7e50-3cdf-cfe5-8986-e77a3c4e0bb8%40gmx.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup stops when the backup file reaches 3Gb

2019-01-28 Thread Mike Keehan

On Fri, 25 Jan 2019 13:52:55 +
Mike Keehan  wrote:

> On Thu, 24 Jan 2019 11:29:50 +
> unman  wrote:
> 
> > On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote:  
> > > On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote:
> > > > Mike Keehan:
> > > > > Hi,
> > > > > 
> > > > > I'm using Qubes Backup to save some of my qubes into another
> > > > > VM. The backup VM has 18 Gb of storage available, but
> > > > > whenever the backup file reaches 3Gb, the backup process just
> > > > > hangs.
> > > > > 
> > > > > No CPU usage, no error messages, just stops.  The backup
> > > > > window shows 40% complete, but never moves any further
> > > > > (different % for different combinations of qubes in the
> > > > > backup list).
> > > > > 
> > > > > After waiting a considerable time (well, 5-10 minutes),
> > > > > hitting Cancel in the backup window does cancel it.  The rest
> > > > > of the system is continuing to work without problem.  Happens
> > > > > every time I try to use Qubes backup.
> > > > > 
> > > > > The Qubes Disk Space widget shows less than 50% disk used
> > > > > overall, the backupVM shows only 18% disk used when the 3Gb
> > > > > file has been saved.
> > > > > 
> > > > > I'm stumped.
> > > > > 
> > > > > Mike.
> > > > 
> > > > Hi,
> > > > 
> > > > You may have to wait longer than 5-10 minutes. I experience
> > > > something similar when doing a full backup, except it's worse
> > > > because i'm backing up like 2.5TB. It appears to hang for
> > > > several hours at a time (and this happens more than once), but
> > > > it does eventually make visible progress again. The whole
> > > > process takes over 24 hours. This is why i do full backups very
> > > > infrequently.
> > > > 
> > > > For you it shouldn't take nearly as long because it's a lot less
> > > > data, but the progress appearing to hang for a while seems to be
> > > > normal.
> > > > 
> > > > I'm using 3.2 tho, and i know they made changes to the backup
> > > > mechanism under the hood in 4.0, so i'm not sure if this issue
> > > > still applies in 4.0.
> > > 
> > > Marek,
> > > 
> > > Isn't this the null bytes bug in GNU tar?
> > > 
> > > https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net
> > > 
> > > It would be a good idea to update this in dom0. My own backup tool
> > > uses GNU tar as well.
> > > 
> > > -- 
> > > 
> > > Chris Laprise, tas...@posteo.net
> > > https://github.com/tasket
> > > https://twitter.com/ttaskett
> > > PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886
> > 
> > It seems a little early to judge.
> > 
> > Mike - it looks from your comment as if you have been trying with
> > subsets of the qubes? Can you confirm if these are running or
> > stopped.
> > 
> > Like jsnow, I'm regularly able to backup far more than 3G without
> > issue, so it looks as if there's something particular about this
> > scenario. It would be helpful if you could confirm the issue when
> > all qubes you are backing up are stopped.
> > Then try bisecting the qubes backup group - keep bisecting if you
> > hit the problem again until you either find the problematic qubes
> > or have backed them all up.
> >   
> 
> OK, progress:)
> 
> I can backup a list of stopped qubes, running out to a 10Gb file
> without any issues.  They all verify OK too.  However, backing up
> running qubes exhibits the problem.  
> 
> Starting up one of these qubes and trying to backup causes the
> progress indicator to stop at some point, BUT, the data is still
> being backed up to disk, and continues flowing for some time.  When
> the data flow stops, then I have to cancel the backup operation.
> However, verifying the backup works OK - file size reported is
> correct, and the verify process finishes successfully.  I haven't
> tried to actually restore one of these yet.
> 
> I tried recording the process status of both dom0 and the backup vm
> during the backups, but could not see any particular process dying
> when the progress updater stopped moving.  The tar processes stopped
> in dom0 but I guess that was because they had finished creating the
> private.img files.
> 
> So it looks like backing up a live VM causes the backup process to
> fail at some point, but not before the data is actually backed up.  
> 
> It doesn't look like a tar null issue as the data does get to disk OK.
> It's just the control of the backup process getting out of step
> somewhere.
> 
> Mike.
> 

I'm trying to debug the backup halting part way when backing up
a running VM.  (I have restored one of these backups successfully!)

The backup.py script shows a debug log can be produced, but I can't
find it - do I have to turn it on somehow?

Mike.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to

Re: [qubes-users] Backup stops when the backup file reaches 3Gb

2019-01-25 Thread Mike Keehan

On Thu, 24 Jan 2019 11:29:50 +
unman  wrote:

> On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote:
> > On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote:  
> > > Mike Keehan:  
> > > > Hi,
> > > > 
> > > > I'm using Qubes Backup to save some of my qubes into another VM.
> > > > The backup VM has 18 Gb of storage available, but whenever the
> > > > backup file reaches 3Gb, the backup process just hangs.
> > > > 
> > > > No CPU usage, no error messages, just stops.  The backup window
> > > > shows 40% complete, but never moves any further (different % for
> > > > different combinations of qubes in the backup list).
> > > > 
> > > > After waiting a considerable time (well, 5-10 minutes), hitting
> > > > Cancel in the backup window does cancel it.  The rest of the
> > > > system is continuing to work without problem.  Happens every
> > > > time I try to use Qubes backup.
> > > > 
> > > > The Qubes Disk Space widget shows less than 50% disk used
> > > > overall, the backupVM shows only 18% disk used when the 3Gb
> > > > file has been saved.
> > > > 
> > > > I'm stumped.
> > > > 
> > > > Mike.  
> > > 
> > > Hi,
> > > 
> > > You may have to wait longer than 5-10 minutes. I experience
> > > something similar when doing a full backup, except it's worse
> > > because i'm backing up like 2.5TB. It appears to hang for several
> > > hours at a time (and this happens more than once), but it does
> > > eventually make visible progress again. The whole process takes
> > > over 24 hours. This is why i do full backups very infrequently.
> > > 
> > > For you it shouldn't take nearly as long because it's a lot less
> > > data, but the progress appearing to hang for a while seems to be
> > > normal.
> > > 
> > > I'm using 3.2 tho, and i know they made changes to the backup
> > > mechanism under the hood in 4.0, so i'm not sure if this issue
> > > still applies in 4.0.  
> > 
> > Marek,
> > 
> > Isn't this the null bytes bug in GNU tar?
> > 
> > https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net
> > 
> > It would be a good idea to update this in dom0. My own backup tool
> > uses GNU tar as well.
> > 
> > -- 
> > 
> > Chris Laprise, tas...@posteo.net
> > https://github.com/tasket
> > https://twitter.com/ttaskett
> > PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886  
> 
> It seems a little early to judge.
> 
> Mike - it looks from your comment as if you have been trying with
> subsets of the qubes? Can you confirm if these are running or stopped.
> 
> Like jsnow, I'm regularly able to backup far more than 3G without
> issue, so it looks as if there's something particular about this
> scenario. It would be helpful if you could confirm the issue when all
> qubes you are backing up are stopped.
> Then try bisecting the qubes backup group - keep bisecting if you hit
> the problem again until you either find the problematic qubes or have
> backed them all up.
> 

OK, progress:)

I can backup a list of stopped qubes, running out to a 10Gb file without
any issues.  They all verify OK too.  However, backing up running qubes
exhibits the problem.  

Starting up one of these qubes and trying to backup causes the progress
indicator to stop at some point, BUT, the data is still being backed up
to disk, and continues flowing for some time.  When the data flow stops,
then I have to cancel the backup operation.  However, verifying the
backup works OK - file size reported is correct, and the verify process
finishes successfully.  I haven't tried to actually restore one of
these yet.

I tried recording the process status of both dom0 and the backup vm
during the backups, but could not see any particular process dying when
the progress updater stopped moving.  The tar processes stopped in dom0
but I guess that was because they had finished creating the private.img
files.

So it looks like backing up a live VM causes the backup process to fail
at some point, but not before the data is actually backed up.  

It doesn't look like a tar null issue as the data does get to disk OK.
It's just the control of the backup process getting out of step
somewhere.

Mike.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190125135255.23ddcca0.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup stops when the backup file reaches 3Gb

2019-01-24 Thread Mike Keehan

On Thu, 24 Jan 2019 11:27:00 -0500
Chris Laprise  wrote:

> On 01/24/2019 06:29 AM, unman wrote:
> > On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote:  
> >> On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote:  
> >>> Mike Keehan:  
>  Hi,
> 
>  I'm using Qubes Backup to save some of my qubes into another VM.
>  The backup VM has 18 Gb of storage available, but whenever the
>  backup file reaches 3Gb, the backup process just hangs.
> 
>  No CPU usage, no error messages, just stops.  The backup window
>  shows 40% complete, but never moves any further (different % for
>  different combinations of qubes in the backup list).
> 
>  After waiting a considerable time (well, 5-10 minutes), hitting
>  Cancel in the backup window does cancel it.  The rest of the
>  system is continuing to work without problem.  Happens every
>  time I try to use Qubes backup.
> 
>  The Qubes Disk Space widget shows less than 50% disk used
>  overall, the backupVM shows only 18% disk used when the 3Gb file
>  has been saved.
> 
>  I'm stumped.
> 
>  Mike.  
> >>>
> >>> Hi,
> >>>
> >>> You may have to wait longer than 5-10 minutes. I experience
> >>> something similar when doing a full backup, except it's worse
> >>> because i'm backing up like 2.5TB. It appears to hang for several
> >>> hours at a time (and this happens more than once), but it does
> >>> eventually make visible progress again. The whole process takes
> >>> over 24 hours. This is why i do full backups very infrequently.
> >>>
> >>> For you it shouldn't take nearly as long because it's a lot less
> >>> data, but the progress appearing to hang for a while seems to be
> >>> normal.
> >>>
> >>> I'm using 3.2 tho, and i know they made changes to the backup
> >>> mechanism under the hood in 4.0, so i'm not sure if this issue
> >>> still applies in 4.0.  
> >>
> >> Marek,
> >>
> >> Isn't this the null bytes bug in GNU tar?
> >>
> >> https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net
> >>
> >> It would be a good idea to update this in dom0. My own backup tool
> >> uses GNU tar as well.
> >>
> >> -- 
> >>
> >> Chris Laprise, tas...@posteo.net
> >> https://github.com/tasket
> >> https://twitter.com/ttaskett
> >> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886  
> > 
> > It seems a little early to judge.
> > 
> > Mike - it looks from your comment as if you have been trying with
> > subsets of the qubes? Can you confirm if these are running or
> > stopped.
> > 
> > Like jsnow, I'm regularly able to backup far more than 3G without
> > issue, so it looks as if there's something particular about this
> > scenario. It would be helpful if you could confirm the issue when
> > all qubes you are backing up are stopped.
> > Then try bisecting the qubes backup group - keep bisecting if you
> > hit the problem again until you either find the problematic qubes
> > or have backed them all up.
> >   
> 
> Oops, I pasted the wrong link. Here is the correct one:
> 
> https://utcc.utoronto.ca/~cks/space/blog/sysadmin/TarFindingTruncateBug
> 
> The symptoms sound remarkably the same... potentially hours-long
> delays with no adverse effect on data. Trigger condition is not about
> size, but due to corner cases that involve backing up nulls.
> 

I left a backup running before I left home this morning - it was stuck
at 1.8Gb then (confirming that size is not the issue), and it was still
at 1.8Gb when I got home this evening.  That was about 8 hours or so.

I have a recollection from my dim and distant past, that I had a similar
stuck tar issue when it could not handle fifos.  Not Linux in those
days.  There is no mention of fifos (or sockets etc.) in the tar
manpage, so I don't know if gnu tar is supposed to handle them or not.
I had to use cpio to backup systems which contained those things.

Anyway, I'll investigate further tomorrow.  You have given me a number
of things to look into.  Thanks,

Mike.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190124193856.01f80d02.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup stops when the backup file reaches 3Gb

2019-01-24 Thread Mike Keehan

On Thu, 24 Jan 2019 11:27:00 -0500
Chris Laprise  wrote:

> On 01/24/2019 06:29 AM, unman wrote:
> > On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote:  
> >> On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote:  
> >>> Mike Keehan:  
>  Hi,
> 
>  I'm using Qubes Backup to save some of my qubes into another VM.
>  The backup VM has 18 Gb of storage available, but whenever the
>  backup file reaches 3Gb, the backup process just hangs.
> 
>  No CPU usage, no error messages, just stops.  The backup window
>  shows 40% complete, but never moves any further (different % for
>  different combinations of qubes in the backup list).
> 
>  After waiting a considerable time (well, 5-10 minutes), hitting
>  Cancel in the backup window does cancel it.  The rest of the
>  system is continuing to work without problem.  Happens every
>  time I try to use Qubes backup.
> 
>  The Qubes Disk Space widget shows less than 50% disk used
>  overall, the backupVM shows only 18% disk used when the 3Gb file
>  has been saved.
> 
>  I'm stumped.
> 
>  Mike.  
> >>>
> >>> Hi,
> >>>
> >>> You may have to wait longer than 5-10 minutes. I experience
> >>> something similar when doing a full backup, except it's worse
> >>> because i'm backing up like 2.5TB. It appears to hang for several
> >>> hours at a time (and this happens more than once), but it does
> >>> eventually make visible progress again. The whole process takes
> >>> over 24 hours. This is why i do full backups very infrequently.
> >>>
> >>> For you it shouldn't take nearly as long because it's a lot less
> >>> data, but the progress appearing to hang for a while seems to be
> >>> normal.
> >>>
> >>> I'm using 3.2 tho, and i know they made changes to the backup
> >>> mechanism under the hood in 4.0, so i'm not sure if this issue
> >>> still applies in 4.0.  
> >>
> >> Marek,
> >>
> >> Isn't this the null bytes bug in GNU tar?
> >>
> >> https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net
> >>
> >> It would be a good idea to update this in dom0. My own backup tool
> >> uses GNU tar as well.
> >>
> >> -- 
> >>
> >> Chris Laprise, tas...@posteo.net
> >> https://github.com/tasket
> >> https://twitter.com/ttaskett
> >> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886  
> > 
> > It seems a little early to judge.
> > 
> > Mike - it looks from your comment as if you have been trying with
> > subsets of the qubes? Can you confirm if these are running or
> > stopped.
> > 
> > Like jsnow, I'm regularly able to backup far more than 3G without
> > issue, so it looks as if there's something particular about this
> > scenario. It would be helpful if you could confirm the issue when
> > all qubes you are backing up are stopped.
> > Then try bisecting the qubes backup group - keep bisecting if you
> > hit the problem again until you either find the problematic qubes
> > or have backed them all up.
> >   
> 
> Oops, I pasted the wrong link. Here is the correct one:
> 
> https://utcc.utoronto.ca/~cks/space/blog/sysadmin/TarFindingTruncateBug
> 
> The symptoms sound remarkably the same... potentially hours-long
> delays with no adverse effect on data. Trigger condition is not about
> size, but due to corner cases that involve backing up nulls.
> 

Thanks to all of you !!

I've been out today, but will have a look at tracking down the culprit
tomorrow:)

Mike.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190124184812.24128610.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup stops when the backup file reaches 3Gb

2019-01-24 Thread Chris Laprise

On 01/24/2019 06:29 AM, unman wrote:

On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote:

On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote:

Mike Keehan:

Hi,

I'm using Qubes Backup to save some of my qubes into another VM.
The backup VM has 18 Gb of storage available, but whenever the
backup file reaches 3Gb, the backup process just hangs.

No CPU usage, no error messages, just stops. The backup window
shows 40% complete, but never moves any further (different % for
different combinations of qubes in the backup list).

After waiting a considerable time (well, 5-10 minutes), hitting
Cancel in the backup window does cancel it. The rest of the
system is continuing to work without problem. Happens every
time I try to use Qubes backup.

The Qubes Disk Space widget shows less than 50% disk used overall,
the backupVM shows only 18% disk used when the 3Gb file has been
saved.

I'm stumped.

Mike.

Hi,

You may have to wait longer than 5-10 minutes. I experience something
similar when doing a full backup, except it's worse because i'm backing
up like 2.5TB. It appears to hang for several hours at a time (and this
happens more than once), but it does eventually make visible progress
again. The whole process takes over 24 hours. This is why i do full
backups very infrequently.

For you it shouldn't take nearly as long because it's a lot less data,
but the progress appearing to hang for a while seems to be normal.

I'm using 3.2 tho, and i know they made changes to the backup mechanism
under the hood in 4.0, so i'm not sure if this issue still applies in
4.0.

Marek,

Isn't this the null bytes bug in GNU tar?

https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net

It would be a good idea to update this in dom0. My own backup tool uses GNU
tar as well.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

It seems a little early to judge.

Mike - it looks from your comment as if you have been trying with
subsets of the qubes? Can you confirm if these are running or stopped.

Like jsnow, I'm regularly able to backup far more than 3G without issue,
so it looks as if there's something particular about this scenario.
It would be helpful if you could confirm the issue when all qubes you
are backing up are stopped.
Then try bisecting the qubes backup group - keep bisecting if you hit
the problem again until you either find the problematic qubes or have
backed them all up.

Oops, I pasted the wrong link. Here is the correct one:

https://utcc.utoronto.ca/~cks/space/blog/sysadmin/TarFindingTruncateBug

The symptoms sound remarkably the same... potentially hours-long delays
with no adverse effect on data. Trigger condition is not about size, but
due to corner cases that involve backing up nulls.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/e7181586-a839-0f44-f7a5-1d1d654f5d58%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup stops when the backup file reaches 3Gb

2019-01-24 Thread unman

On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote:
> On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote:
> > Mike Keehan:
> > > Hi,
> > > 
> > > I'm using Qubes Backup to save some of my qubes into another VM.
> > > The backup VM has 18 Gb of storage available, but whenever the
> > > backup file reaches 3Gb, the backup process just hangs.
> > > 
> > > No CPU usage, no error messages, just stops.  The backup window
> > > shows 40% complete, but never moves any further (different % for
> > > different combinations of qubes in the backup list).
> > > 
> > > After waiting a considerable time (well, 5-10 minutes), hitting
> > > Cancel in the backup window does cancel it.  The rest of the
> > > system is continuing to work without problem.  Happens every
> > > time I try to use Qubes backup.
> > > 
> > > The Qubes Disk Space widget shows less than 50% disk used overall,
> > > the backupVM shows only 18% disk used when the 3Gb file has been
> > > saved.
> > > 
> > > I'm stumped.
> > > 
> > > Mike.
> > 
> > Hi,
> > 
> > You may have to wait longer than 5-10 minutes. I experience something
> > similar when doing a full backup, except it's worse because i'm backing
> > up like 2.5TB. It appears to hang for several hours at a time (and this
> > happens more than once), but it does eventually make visible progress
> > again. The whole process takes over 24 hours. This is why i do full
> > backups very infrequently.
> > 
> > For you it shouldn't take nearly as long because it's a lot less data,
> > but the progress appearing to hang for a while seems to be normal.
> > 
> > I'm using 3.2 tho, and i know they made changes to the backup mechanism
> > under the hood in 4.0, so i'm not sure if this issue still applies in
> > 4.0.
> 
> Marek,
> 
> Isn't this the null bytes bug in GNU tar?
> 
> https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net
> 
> It would be a good idea to update this in dom0. My own backup tool uses GNU
> tar as well.
> 
> -- 
> 
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

It seems a little early to judge.

Mike - it looks from your comment as if you have been trying with
subsets of the qubes? Can you confirm if these are running or stopped.

Like jsnow, I'm regularly able to backup far more than 3G without issue,
so it looks as if there's something particular about this scenario.
It would be helpful if you could confirm the issue when all qubes you
are backing up are stopped.
Then try bisecting the qubes backup group - keep bisecting if you hit
the problem again until you either find the problematic qubes or have
backed them all up.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190124112950.ldybghvvpc5jham4%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup stops when the backup file reaches 3Gb

2019-01-23 Thread Chris Laprise

On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote:

Mike Keehan:

Hi,

I'm using Qubes Backup to save some of my qubes into another VM.
The backup VM has 18 Gb of storage available, but whenever the
backup file reaches 3Gb, the backup process just hangs.

No CPU usage, no error messages, just stops. The backup window
shows 40% complete, but never moves any further (different % for
different combinations of qubes in the backup list).

The Qubes Disk Space widget shows less than 50% disk used overall,
the backupVM shows only 18% disk used when the 3Gb file has been
saved.

I'm stumped.

Mike.

Hi,

For you it shouldn't take nearly as long because it's a lot less data,
but the progress appearing to hang for a while seems to be normal.

I'm using 3.2 tho, and i know they made changes to the backup mechanism
under the hood in 4.0, so i'm not sure if this issue still applies in 4.0.

Marek,

Isn't this the null bytes bug in GNU tar?

https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net

It would be a good idea to update this in dom0. My own backup tool uses
GNU tar as well.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/54678bc8-8091-fb49-92ac-7ad1b59e42d4%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup stops when the backup file reaches 3Gb

2019-01-23 Thread jsnow

Mike Keehan:

Hi,

I'm using Qubes Backup to save some of my qubes into another VM.
The backup VM has 18 Gb of storage available, but whenever the
backup file reaches 3Gb, the backup process just hangs.

No CPU usage, no error messages, just stops. The backup window
shows 40% complete, but never moves any further (different % for
different combinations of qubes in the backup list).

The Qubes Disk Space widget shows less than 50% disk used overall,
the backupVM shows only 18% disk used when the 3Gb file has been
saved.

I'm stumped.

Mike.

Hi,

For you it shouldn't take nearly as long because it's a lot less data,
but the progress appearing to hang for a while seems to be normal.

I'm using 3.2 tho, and i know they made changes to the backup mechanism
under the hood in 4.0, so i'm not sure if this issue still applies in 4.0.

--
Jackie

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/5406576f-66c0-3af8-d74e-fbb6b9d4a952%40bitmessage.ch.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Backup stops when the backup file reaches 3Gb

2019-01-23 Thread Mike Keehan

Hi,

I'm using Qubes Backup to save some of my qubes into another VM.
The backup VM has 18 Gb of storage available, but whenever the
backup file reaches 3Gb, the backup process just hangs.

No CPU usage, no error messages, just stops.  The backup window
shows 40% complete, but never moves any further (different % for
different combinations of qubes in the backup list).

After waiting a considerable time (well, 5-10 minutes), hitting
Cancel in the backup window does cancel it.  The rest of the
system is continuing to work without problem.  Happens every
time I try to use Qubes backup.

The Qubes Disk Space widget shows less than 50% disk used overall,
the backupVM shows only 18% disk used when the 3Gb file has been
saved.

I'm stumped.

Mike.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190123174938.1371fa26.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] BACKUP IMPORTANT VMS Q4

2018-12-22 Thread amapaps


> Mount to a live system or use the install disk and use rescue mode.
> I'm assuming that you have something like a standard install on /dev/sda
> (boot in /dev/sda1 and data in /dev/sda2?)
> You can check this from the prompt by running cfdisk /dev/sda,  to see
> how the disk is configured.
> Once you know how the disk is configured, use lvm tools to dig into it.
> lvmdiskscan will show you the volumes.
> lvscan will show you the status of the drives.
> lvdisplay will show you the LV and VG names.
> 
> vgchange -ay will make the volumes active, and lvscan should then show
> you the appropriate volumes: 
> /dev/qubes_dom0/root
> 
> Then you should be able to mount /dev/qubes_dom0/root and back up the VM
> data from there.
> 
> If you need more help  or something doesnt look right, just ask.
> (Cloning the disk was a good move, and would have been my first bit of
> advice.)

Thank you, you solved my problem, i can mount the disk now

What should i backup? I mounted: /dev/qubes_dom0/root, went to 
/var/lib/qubes/appvms/  and it shows all my vms, but i open any folder and 
theres only 2 files: Firewall.xml, and icon.png
What should i backup? Is there another folder i can get the files from my vms?
Thank you, i will make a backup using qubes so this doesnt happen again

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0b44ae29-28b3-4eb6-a033-403f1ec04867%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] BACKUP IMPORTANT VMS Q4

2018-12-22 Thread unman

On Fri, Dec 21, 2018 at 09:52:29PM -0800, amap...@gmail.com wrote:
> Hello, im using qubes os 4, i updated all the VMs + updated dom0
> When i turned on my pc, Qubes os didnt get recognized at boot menu, i have 
> tried a lot of things and now im tired, i just want to backup my vms and i 
> will make a fresh install. I have saw a lot of tutorials but im not that 
> familiar with disk partitions, logical volumes etc. Can someone please tell 
> me step by step how to backup the important vms? I have tried mounting the 
> drive to a live system but i cant mount it, i always get this issue: mount: 
> /mnt: unknown filesystem type 'LVM2_member'.
> 
> Encrypted partition with all vm data: /dev/sda
> 
> I cloned the disk in case something goes wrong. 
> Hope you can help me!
> 

Mount to a live system or use the install disk and use rescue mode.
I'm assuming that you have something like a standard install on /dev/sda
(boot in /dev/sda1 and data in /dev/sda2?)
You can check this from the prompt by running cfdisk /dev/sda,  to see
how the disk is configured.
Once you know how the disk is configured, use lvm tools to dig into it.
lvmdiskscan will show you the volumes.
lvscan will show you the status of the drives.
lvdisplay will show you the LV and VG names.

vgchange -ay will make the volumes active, and lvscan should then show
you the appropriate volumes: 
/dev/qubes_dom0/root

Then you should be able to mount /dev/qubes_dom0/root and back up the VM
data from there.

If you need more help  or something doesnt look right, just ask.
(Cloning the disk was a good move, and would have been my first bit of
advice.)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20181222132021.psi36jxdrxvq4dir%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] BACKUP IMPORTANT VMS Q4

2018-12-21 Thread amapaps

Hello, im using qubes os 4, i updated all the VMs + updated dom0
When i turned on my pc, Qubes os didnt get recognized at boot menu, i have 
tried a lot of things and now im tired, i just want to backup my vms and i will 
make a fresh install. I have saw a lot of tutorials but im not that familiar 
with disk partitions, logical volumes etc. Can someone please tell me step by 
step how to backup the important vms? I have tried mounting the drive to a live 
system but i cant mount it, i always get this issue: mount: /mnt: unknown 
filesystem type 'LVM2_member'.

Encrypted partition with all vm data: /dev/sda

I cloned the disk in case something goes wrong. 
Hope you can help me!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/48604034-a64c-4f6a-b9b2-5a2091b0b044%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup verification error

2018-10-17 Thread Chris Laprise

On 10/17/2018 06:13 PM, 'awokd' via qubes-users wrote:

Kelly Dean wrote on 10/17/18 6:00 PM:
On Qubes 4.0, I did a full backup to an external hard drive using the
standard backup utility, which completed successfully. 225GB total,
compressed 130GB, took about 12 hours.

Then I tried to verify it (restore with verify-only option), and
watched it for a few minutes to make sure it was running ok, then left
it alone. Last line in the message window at the time was:

Extracting data: 209.6 GiB to restore

Came back a few hours later and the next line was:
Finished with errors!

And there was a dialog box:

[Dom0] Backup error!
ERROR: failed to decrypt
/var/tmp/restorexnuw0a8p/vm31/private.img.034.enc: b'scrypt:
Decrypting file would take too much CPU time\n'
Partially restored files left in /var/tmp/restore_*, investigate them
and/or clean them up
OK

So now I don't know if I have a good backup. The error message also
leaves me doubtful that I'd be able to restore the backup even if it
is good.

The indicated file doesn't exist in dom0. Neither does any other
/var/tmp/restore* file. Googling the message (Decrypting file would
take too much CPU time) finds nothing.

Looks like that error string comes from scrypt. There is a command line
option (-f) to scrypt that forces it to proceed even if it might take
excessive memory or CPU time, but I'm not sure how to pass it on through
qubes-backup-restore.

Looking at the scrypt source, this error code results from the estimated
number of operations exceeding a max time limit. Using -f should
override this check.

In restore.py the function 'def launch_scrypt' contains the line
starting with:

command_line = ['scrypt', action, input_name

This could be changed to:

command_line = ['scrypt', action, '-f', input_name

Of course, this advice is offered "at your own risk" and a backup copy
of restore.py should be made before doing any modification.

BTW, since your backups are rather large, you might be interested in a
new backup tool I'm writing that can perform fast incremental backups
even on large volumes:

https://github.com/tasket/sparsebak

Its still experimental but could be in beta as soon as December.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/ddd8b81d-9558-9bfc-aeee-a950e3236cb4%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup verification error

2018-10-17 Thread 'awokd' via qubes-users

Kelly Dean wrote on 10/17/18 6:00 PM:

On Qubes 4.0, I did a full backup to an external hard drive using the standard
backup utility, which completed successfully. 225GB total, compressed 130GB,
took about 12 hours.

Then I tried to verify it (restore with verify-only option), and watched it for
a few minutes to make sure it was running ok, then left it alone. Last line in
the message window at the time was:
Extracting data: 209.6 GiB to restore

Came back a few hours later and the next line was:
Finished with errors!

And there was a dialog box:

So now I don't know if I have a good backup. The error message also leaves me
doubtful that I'd be able to restore the backup even if it is good.

The indicated file doesn't exist in dom0. Neither does any other
/var/tmp/restore* file. Googling the message (Decrypting file would take too
much CPU time) finds nothing.

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/88ea4d17-f523-9813-d73c-0c16ac1a3ea0%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup verification error

2018-10-17 Thread taii...@gmx.com

Considering how long it takes and the chance for errors I also make a
post fsck dd backup of the entire drive/partition and then sha1sum it
just in case, which has saved me a few times.

I wish there was a choice to use more RAM to make it go faster or what not.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5297d787-63b2-5814-39c3-30e94bb31484%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Backup verification error

2018-10-17 Thread Kelly Dean

On Qubes 4.0, I did a full backup to an external hard drive using the standard
backup utility, which completed successfully. 225GB total, compressed 130GB,
took about 12 hours.

Came back a few hours later and the next line was:
Finished with errors!

And there was a dialog box:

So now I don't know if I have a good backup. The error message also leaves me
doubtful that I'd be able to restore the backup even if it is good.

The indicated file doesn't exist in dom0. Neither does any other
/var/tmp/restore* file. Googling the message (Decrypting file would take too
much CPU time) finds nothing.

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/65fJMu1t2Tij2ncYtCIPMXZngqVKtVVw1ULOeAOmJPX%40local.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] BACKUP PROBLEM

2018-05-13 Thread higginsonjim2

Thanks for comments. To clarify - i’m only using qubes4 vm’s and templates. In
ideal world, i ‘d use clonezilla say to clone everything and copy the
clonezilla image back if i ever thought there was a problem with active system.
This does not seem possible with qubes. (This process is simple and works well
with debian, ubuntu etc)
Instead I’ve copied all my qubes3.2 data offline and was intending to use
filezilla to bring it all back -once i was confident of stable qubes4 setup.
I think i’m further away from ever with that. Just done the umpteenth install
of qubes4 and now can’t get my test vm’s to recognise software eg filezilla,
libreoffice writer that i’ ve added to fedora 26. I done endless resume,
stop/starts and turn pc off/on - but nothing happening. Was intending to
generate a fedora-26 template backup again, including a few test vm’s - then
transfer to another pc , then do a fresh install on main pc, zap the new
fedora-26 and vm’s and then try and copy the backup file to main pc and restore.
Qubes is a great idea - for 12 months or so i’ve done almost all my internet
stuff on dispvm’s and kept a good discipline wrt untusted/ personal vm’s etc.
My old pc couldn’t handle qubes4 - so ive invested in new kit so i could start
with qubes4.

I can’t spend any more time with this so it’s back to debian for me.
I’ll have another look at qubes in a few months when hopefully it’s more stable.

Thanks again for comments.

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/274633a8-90c4-49ca-9193-9aabede65d68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] BACKUP PROBLEM

2018-05-13 Thread awokd

On Sun, May 13, 2018 1:58 pm, higginsonj...@gmail.com wrote:
>
> Just posted a comment on earlier BACKUP problem where message appeared
>
> "Backup header retrieval failed (exit code 2)" after qvm-backup restore.
>
>
> Tried a simpler backup this time - just fedora-26 template and a small
> personal VM.
>
> Process seemed to go OK - but following backup - was left with fedora-26
> template and fedora-261 template. (Think others have seen this also)

You mean on restore, right? I saw that on mine too, it wanted to create
some 0 byte DispVMs so I didn't include those on the restore. Note too
that you should only be restoring your AppVMs and StandaloneVMs and using
the templates that come with 4.0 instead. See
https://www.qubes-os.org/doc/upgrade-to-r4.0/#restore-from-your-backup:

"We recommend that you restore only your TemplateBasedVMs and
StandaloneVMs from R3.2. Using TemplateVMs and SystemVMs from R3.2 is not
fully supported (see #3514). Instead, we recommend using the TemplateVMs
that were created specifically for R4.0"

> Trying to get rid of fedora-261 template. Normal process won't allow it -
> so tried "REMOVE VM's MANUALLY" approach as per docs.
> First 3 instructions seem OK - but final one achieves nothing since there
> is no content in the "applications-merged" folder.

Looks like this doc is for R3.2 only and I missed it! I submitted an edit.
If you have nothing else on your R4.0 installation, it might be faster to
just reinstall it.

> Hence can't remove FEDORA-261 from QUBES MANAGER.
>
> Note ALSO - the FEDORA-261 template created does not include any
> APPLICATIONS from the FEDORA-26 template I stared with.
>
> SPECIFICALLY - it contains none at all!
>
> This seems similar to problems I encountered before with QUBES 4.
>
> 1) With QUBES3.2 - I used DEBIAN template - but have had to give up on
> that as I can't get any applications to show within DEBIAN template and
> have no means to add any.  eg no TERMINAL
>
> 2) WIth QUBES 3.2 I also used a STANDALONE template for development work.
>
> Again - even if it's based on FEDORA-26 template - I get no APPLICATIONS
> available to me and NO terminal.
>
> Basically I have given up on STANDALONE VM also.
>
>
> I can install QUBES4 quickly and get what appears to be a workable system
> - but am loathe to commit to it as every step I take seems to offer more
> problems.
> QUBES3.2 was simple and straightforward  - and just seemed to work.
> Am basically trying to get everything setup on new computer but after many
> many days of trying (2 or 3 weeks of effort)- I cant achieve a stable
> state
>
> No Debian
> No Standalone
> No BACKUP working consistently
> Duplicated template - can't get rid from menu
> QUBES manager clunky
> Struggling to get rid of DISPOSABLE VM template(based on Fedora-26 when I
> updated main template to fedora-27.
> DispVM - quite slow compared to QUBES3.2
>
> HAS ANYONE PREPARED AND USED BACKUPS SUCCESSFULLY ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/55328bb9-688e-4186-ab78-8d160c22e27e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e931199dc42b3467df788af401806d5d%40elude.in.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] BACKUP PROBLEM

2018-05-13 Thread higginsonjim2

Just posted a comment on earlier BACKUP problem where message appeared

"Backup header retrieval failed (exit code 2)" after qvm-backup restore.

Tried a simpler backup this time - just fedora-26 template and a small personal
VM.

Process seemed to go OK - but following backup - was left with fedora-26
template and fedora-261 template. (Think others have seen this also)

Trying to get rid of fedora-261 template. Normal process won't allow it - so
tried "REMOVE VM's MANUALLY" approach as per docs.
First 3 instructions seem OK - but final one achieves nothing since there is no
content in the "applications-merged" folder.

Hence can't remove FEDORA-261 from QUBES MANAGER.

Note ALSO - the FEDORA-261 template created does not include any APPLICATIONS
from the FEDORA-26 template I stared with.

SPECIFICALLY - it contains none at all!

This seems similar to problems I encountered before with QUBES 4.

1) With QUBES3.2 - I used DEBIAN template - but have had to give up on that as
I can't get any applications to show within DEBIAN template and have no means
to add any. eg no TERMINAL

2) WIth QUBES 3.2 I also used a STANDALONE template for development work.

Again - even if it's based on FEDORA-26 template - I get no APPLICATIONS
available to me and NO terminal.

Basically I have given up on STANDALONE VM also.

I can install QUBES4 quickly and get what appears to be a workable system - but
am loathe to commit to it as every step I take seems to offer more problems.
QUBES3.2 was simple and straightforward - and just seemed to work.
Am basically trying to get everything setup on new computer but after many many
days of trying (2 or 3 weeks of effort)- I cant achieve a stable state

No Debian
No Standalone
No BACKUP working consistently
Duplicated template - can't get rid from menu
QUBES manager clunky
Struggling to get rid of DISPOSABLE VM template(based on Fedora-26 when I
updated main template to fedora-27.
DispVM - quite slow compared to QUBES3.2

HAS ANYONE PREPARED AND USED BACKUPS SUCCESSFULLY ?

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/55328bb9-688e-4186-ab78-8d160c22e27e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Backup header retrieval failed (exit code 2) after qvm-backup restore

2017-08-03 Thread Grzesiek Chodzicki

After attempting to restore vm backup, following error message is displayed:
Backup header retrieval failed (exit code 2)

Since this message appears regardless of the passphrase entered I assume it 
means that the passphrase is incorrect. Am I right? If not, what else does this 
message indicate?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0b3584ea-8ed1-4428-a9c6-623316058e86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] backup data from multiple VMs to a single USB-storage device

2017-07-19 Thread josefh . maier

Hello List
Due to different security concerns I will install Mail and
Internet-browsing in different dedicated Windows VM's.

Is there a way to share the USB-storage device between different VM's
for
backup-purposes?
Thank's a lot for any feedback!

Joe

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170719151735.C228720151%40smtp.hushmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup Error

2017-04-03 Thread jimmy . dack . 68


> Likely the filesystem (FAT?) on the destination cannot handle files over 
> a certain size. You may want to reformat it with a native Linux fs like 
> Ext4.
> 
> -- 
> 
> Chris Laprise, tas...@openmailbox.org
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

That was indeed the issue, thanks for the insight and suggestion!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/81bc0cac-c133-49ec-9974-1c3872dd555c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup Error

2017-04-03 Thread jimmy . dack . 68

On Friday, March 17, 2017 at 3:31:37 PM UTC-4, Chris Laprise wrote:
> On 03/17/2017 02:55 PM, jimmy.dack...@gmail.com wrote:
> > I'm trying out the backup feature in Qubes but getting an error.
> >
> > I'm trying to save VMs totaling 22.4GB in size on a USB stick with 63GB 
> > free.
> >
> > At 19% progress is get:
> > "[Dom0] Backup error!
> > ERROR: Failed to write the backup, VM output: cat: write error: File too 
> > large."
> >
> > Is there a maximum file size for backups? A RAM limitation (I have 8GB RAM 
> > and when I do the backup about 6GB is free)? Something else I'm not 
> > thinking of?
> >
> > I am able to do a small backup, such as just Dom0 itself.
> >
> > Also a general question about backups: if I do a backup and then restore, 
> > will it add what I backed up to what is already on the system? Or 
> > completely overwrite everything? For example, if I have 10 VMs and backup 
> > 3, then restore the 3, will it just overwrite those three and leave the 
> > other 7 alone? Or will I only have those 3 and the other 7 are wiped out?
> >
> 
> Likely the filesystem (FAT?) on the destination cannot handle files over 
> a certain size. You may want to reformat it with a native Linux fs like 
> Ext4.
> 5Bp9975@cB%m0wkX
> -- 
> 
> Chris Laprise, tas...@openmailbox.org
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

That was indeed the issue, thanks for the insight!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fd093e5a-5e9b-4330-a11e-3f783b09bc3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup Error

2017-03-17 Thread Todd Lasman

On 2017-03-17 11:55, jimmy.dack...@gmail.com wrote:

I'm trying out the backup feature in Qubes but getting an error.

I'm trying to save VMs totaling 22.4GB in size on a USB stick with 63GB
free.

At 19% progress is get:
"[Dom0] Backup error!
ERROR: Failed to write the backup, VM output: cat: write error: File
too large."

Is there a maximum file size for backups? A RAM limitation (I have 8GB
RAM and when I do the backup about 6GB is free)? Something else I'm
not thinking of?

I am able to do a small backup, such as just Dom0 itself.

Also a general question about backups: if I do a backup and then
restore, will it add what I backed up to what is already on the
system? Or completely overwrite everything? For example, if I have 10
VMs and backup 3, then restore the 3, will it just overwrite those
three and leave the other 7 alone? Or will I only have those 3 and the
other 7 are wiped out?

Also, be sure you didn't make the mistake I made once. I (stupidly)
mounted by backup USB stick in Dom0. Then, when backing up Dom0, it
tried to back up all the data on the backup stick, which of course kept
increasing in size as more stuff got backed up onto it. I've since
learned to use a USBVM, and mount the stick in a dedicated BackupVM.

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/10747aff541781e0d2738fb6c6ca7f97%40nowlas.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup Error

2017-03-17 Thread Unman

On Fri, Mar 17, 2017 at 03:31:24PM -0400, Chris Laprise wrote:
> On 03/17/2017 02:55 PM, jimmy.dack...@gmail.com wrote:
> >I'm trying out the backup feature in Qubes but getting an error.
> >
> >I'm trying to save VMs totaling 22.4GB in size on a USB stick with 63GB free.
> >
> >At 19% progress is get:
> >"[Dom0] Backup error!
> >ERROR: Failed to write the backup, VM output: cat: write error: File too 
> >large."
> >
> >Is there a maximum file size for backups? A RAM limitation (I have 8GB RAM 
> >and when I do the backup about 6GB is free)? Something else I'm not thinking 
> >of?
> >
> >I am able to do a small backup, such as just Dom0 itself.
> >
> >Also a general question about backups: if I do a backup and then restore, 
> >will it add what I backed up to what is already on the system? Or completely 
> >overwrite everything? For example, if I have 10 VMs and backup 3, then 
> >restore the 3, will it just overwrite those three and leave the other 7 
> >alone? Or will I only have those 3 and the other 7 are wiped out?
> >
> 
> Likely the filesystem (FAT?) on the destination cannot handle files over a
> certain size. You may want to reformat it with a native Linux fs like Ext4.
> 

To answer your general question, the restore operation will tell you
there is an existing qube with the same name and wont allow you to
overwrite it.
It certainly wont delete qubes not included in the restore.

As always the command line tool offers many more options and more
granular control - it still wont act on qubes not involved in the
restore operation, (unless you are doing something to their template
obviously.)

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170317212124.GC1810%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup Error

2017-03-17 Thread Chris Laprise

On 03/17/2017 02:55 PM, jimmy.dack...@gmail.com wrote:

I'm trying out the backup feature in Qubes but getting an error.

I'm trying to save VMs totaling 22.4GB in size on a USB stick with 63GB free.

At 19% progress is get:
"[Dom0] Backup error!
ERROR: Failed to write the backup, VM output: cat: write error: File too large."

Is there a maximum file size for backups? A RAM limitation (I have 8GB RAM and
when I do the backup about 6GB is free)? Something else I'm not thinking of?

I am able to do a small backup, such as just Dom0 itself.

Also a general question about backups: if I do a backup and then restore, will
it add what I backed up to what is already on the system? Or completely
overwrite everything? For example, if I have 10 VMs and backup 3, then restore
the 3, will it just overwrite those three and leave the other 7 alone? Or will
I only have those 3 and the other 7 are wiped out?

Likely the filesystem (FAT?) on the destination cannot handle files over
a certain size. You may want to reformat it with a native Linux fs like
Ext4.

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/07c70ef9-0e9f-336b-1c04-2c2920d55e72%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Backup Error

2017-03-17 Thread jimmy . dack . 68

I'm trying out the backup feature in Qubes but getting an error.

I'm trying to save VMs totaling 22.4GB in size on a USB stick with 63GB free.

At 19% progress is get:
"[Dom0] Backup error!
ERROR: Failed to write the backup, VM output: cat: write error: File too large."

Is there a maximum file size for backups? A RAM limitation (I have 8GB RAM and 
when I do the backup about 6GB is free)? Something else I'm not thinking of?

I am able to do a small backup, such as just Dom0 itself.

Also a general question about backups: if I do a backup and then restore, will 
it add what I backed up to what is already on the system? Or completely 
overwrite everything? For example, if I have 10 VMs and backup 3, then restore 
the 3, will it just overwrite those three and leave the other 7 alone? Or will 
I only have those 3 and the other 7 are wiped out?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ec923dfc-2611-4523-a7f8-61470f64725c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup error - where is the log?

2017-02-26 Thread Zbigniew Łukasiak

If I install a second Qubes system on a different partition - is there
any way to copy the VMs from the first one? Because that was my goal
with the backups. It is possible that the lack of space somehow
corrupted the system - and that is the reason for the problems with
backups - so maybe there is any other way to do that?

Z.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAGL_UUvMPW%3D6LteSw_gA3C%2B3jVyNbruc8BvuCRinfjy6c-77BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup error - where is the log?

2017-02-24 Thread Zbigniew Łukasiak

I removed some templates - and now there is no error about no disk
space - but when restoring I still get the same error.

It might be indeed about the path fed to tar - because when creating
the archive I also get errors when I try to archive to a file in the
current dir without giving the full path - it looks like the variable
base_backup_dir does not get initialized, see below for the output.
Backing up worked when I gave it a full path - still failing at
restoring time.

Z.

==

[zby@dom0 ~]$ qvm-backup -x dom0 -x anon-whonix  -x sys-net -x
sys-firewall -x sys-whonix -x python-anaconda backup
--+--+--+
   VM | type | size |
--+--+--+
untrusted |AppVM | 16.0 KiB |
 personal |AppVM |0 |
myovm |AppVM |  5.0 GiB |
my-new-vm |AppVM |  9.9 GiB |
 exch |AppVM |315.8 MiB |
--+--+--+
  Total size: |15.1 GiB |
--+--+--+
VMs not selected for backup:
anon-whonix
debian-8
debian-8-python
dom0
fedora-23
fedora-23-dvm
python-anaconda
sys-firewall
sys-net
sys-whonix
whonix-gw
whonix-ws
Traceback (most recent call last):
  File "/usr/bin/qvm-backup", line 218, in 
main()
  File "/usr/bin/qvm-backup", line 141, in main
stat = os.statvfs(os.path.dirname(base_backup_dir))
OSError: [Errno 2] No such file or directory: ''


On Fri, Feb 24, 2017 at 9:27 AM, Marek Marczykowski-Górecki
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Fri, Feb 24, 2017 at 08:23:00AM -0500, Zbigniew Łukasiak wrote:
>> Ok - I tried the command line version - the output is below. The same
>> error I see in ~/.xsession-errors. It looks to work correctly with the
>> symlinked tmp - but still fails somehow - maybe the archive is
>> corrupted.
>>
>> I tried to re-make the bacup from commandline, and this reports
>> "qvm-backup: export error: [Errno 28] No space left on device" - even
>> though I have enough space on both the /home and the /var/tmp
>> partitions. See below for details - I mounted quite a big partition on
>> /var/tmp. Maybe it somehow still uses the root partition. I did not
>> see that error when running backup from Qubes Manager - but maybe the
>> problem was still there and it was corrupting the backup.
>>
>>
>>
>>
>> [zby@dom0 ~]$ qvm-backup-restore qubes-2017-02-22T111605 --verify-only 
>> --debug
>> Please enter the passphrase to verify and (if encrypted) decrypt the backup:
>> Checking backup content...
>> Working in temporary dir:/var/tmp/restore_RxbZ1b
>> Extracting data: 1.0 MiB to restore
>> Run command[u'tar', u'-ixvf', 'qubes-2017-02-22T111605', u'-C',
>> u'/var/tmp/restore_RxbZ1b', u'backup-header', u'backup-header.hmac',
>> u'qubes.xml.000', u'qubes.xml.000.hmac']
>> Got backup header and hmac: backup-header, backup-header.hmac
>> Verifying file /var/tmp/restore_RxbZ1b/backup-header
>> Loading hmac for file /var/tmp/restore_RxbZ1b/backup-header
>> File verification OK -> Sending file /var/tmp/restore_RxbZ1b/backup-header
>> Creating pipe in: /var/tmp/restore_RxbZ1b/restore_pipe
>> Getting new file:qubes.xml.000
>> Getting hmac:qubes.xml.000.hmac
>> Verifying file /var/tmp/restore_RxbZ1b/qubes.xml.000
>> Started sending thread
>> Moving to dir /var/tmp/restore_RxbZ1b
>> Loading hmac for file /var/tmp/restore_RxbZ1b/qubes.xml.000
>> File verification OK -> Sending file /var/tmp/restore_RxbZ1b/qubes.xml.000
>> Getting new file:
>> Waiting for the extraction process to finish...Extracting file
>> /var/tmp/restore_RxbZ1b/qubes.xml.000
>>
>> Running command [u'tar', u'-xkv',
>> u'../../../../var/tmp/restore_RxbZ1b/qubes.xml']
>
> This path looks strange. AFAIR it's calculated as "path to
> /var/tmp/restore_RxbZ1b/qubes.xml, relative to /var/tmp/restore_RxbZ1b".
> Have you actually mounted something on /var/tmp, or used a symlink? You
> can use mount --bind if you don't want to mount the whole device there.
> And be sure do to it before launching qvm-backup-restore, not during it.
>
>> ===
>>
>>
>> [zby@dom0 ~]$ df
>> Filesystem 1K-blocks  Used Available Use% Mounted on
>> devtmpfs 2002988 0   2002988   0% /dev
>> tmpfs2014408308256   1706152  16% /dev/shm
>> tmpfs2014408  1316   2013092   1% /run
>> tmpfs2014408 0   2014408   0% /sys/fs/cgroup
>> /dev/dm-1   95989516  92623640 0 100% /
>
> Having / full is a problem anyway. Even if large files are placed in
> /var/tmp. You need to clean up something - maybe old content of
> /var/tmp? Or some old logs in /var/log?
>
>> tmpfs201440852   2014356   1% /tmp
>> xenstore

Re: [qubes-users] Backup error - where is the log?

2017-02-24 Thread Marek Marczykowski-Górecki

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, Feb 24, 2017 at 08:23:00AM -0500, Zbigniew Łukasiak wrote:
> Ok - I tried the command line version - the output is below. The same
> error I see in ~/.xsession-errors. It looks to work correctly with the
> symlinked tmp - but still fails somehow - maybe the archive is
> corrupted.
> 
> I tried to re-make the bacup from commandline, and this reports
> "qvm-backup: export error: [Errno 28] No space left on device" - even
> though I have enough space on both the /home and the /var/tmp
> partitions. See below for details - I mounted quite a big partition on
> /var/tmp. Maybe it somehow still uses the root partition. I did not
> see that error when running backup from Qubes Manager - but maybe the
> problem was still there and it was corrupting the backup.
> 
> 
> 
> 
> [zby@dom0 ~]$ qvm-backup-restore qubes-2017-02-22T111605 --verify-only --debug
> Please enter the passphrase to verify and (if encrypted) decrypt the backup:
> Checking backup content...
> Working in temporary dir:/var/tmp/restore_RxbZ1b
> Extracting data: 1.0 MiB to restore
> Run command[u'tar', u'-ixvf', 'qubes-2017-02-22T111605', u'-C',
> u'/var/tmp/restore_RxbZ1b', u'backup-header', u'backup-header.hmac',
> u'qubes.xml.000', u'qubes.xml.000.hmac']
> Got backup header and hmac: backup-header, backup-header.hmac
> Verifying file /var/tmp/restore_RxbZ1b/backup-header
> Loading hmac for file /var/tmp/restore_RxbZ1b/backup-header
> File verification OK -> Sending file /var/tmp/restore_RxbZ1b/backup-header
> Creating pipe in: /var/tmp/restore_RxbZ1b/restore_pipe
> Getting new file:qubes.xml.000
> Getting hmac:qubes.xml.000.hmac
> Verifying file /var/tmp/restore_RxbZ1b/qubes.xml.000
> Started sending thread
> Moving to dir /var/tmp/restore_RxbZ1b
> Loading hmac for file /var/tmp/restore_RxbZ1b/qubes.xml.000
> File verification OK -> Sending file /var/tmp/restore_RxbZ1b/qubes.xml.000
> Getting new file:
> Waiting for the extraction process to finish...Extracting file
> /var/tmp/restore_RxbZ1b/qubes.xml.000
> 
> Running command [u'tar', u'-xkv',
> u'../../../../var/tmp/restore_RxbZ1b/qubes.xml']

This path looks strange. AFAIR it's calculated as "path to
/var/tmp/restore_RxbZ1b/qubes.xml, relative to /var/tmp/restore_RxbZ1b".
Have you actually mounted something on /var/tmp, or used a symlink? You
can use mount --bind if you don't want to mount the whole device there.
And be sure do to it before launching qvm-backup-restore, not during it.

> ===
> 
> 
> [zby@dom0 ~]$ df
> Filesystem 1K-blocks  Used Available Use% Mounted on
> devtmpfs 2002988 0   2002988   0% /dev
> tmpfs2014408308256   1706152  16% /dev/shm
> tmpfs2014408  1316   2013092   1% /run
> tmpfs2014408 0   2014408   0% /sys/fs/cgroup
> /dev/dm-1   95989516  92623640 0 100% /

Having / full is a problem anyway. Even if large files are placed in
/var/tmp. You need to clean up something - maybe old content of
/var/tmp? Or some old logs in /var/log?

> tmpfs201440852   2014356   1% /tmp
> xenstore 2014408   240   2014168   1% /var/lib/xenstored
> /dev/sda11   1889292184884   1590388  11% /boot
> /dev/dm-3  288243040  67263564 206314468  25% /home
> tmpfs 402884 0402884   0% /run/user/991
> tmpfs 402884 8402876   1% /run/user/1000
> /dev/sda7  272256456 167991052  90412476  66% /home/zby/tmp

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYsELWAAoJENuP0xzK19cs4sIH/3xTOfvVJ3RmfzdoXAfz85Z2
QH1loLH347X5omAENt+4HwhzlTq84LZFGKwRWMEgSDQUuj67saas711x5+ybH47N
riswwTJfRC6SrEKPO27/QIN/JSGhCi1h+kmco9UxQSvaovSD0iSBoHsUui2iSvfL
4JfszFiWWVAsOZJu2nJdFOQPH7e69yKBC/hwMX+6PhP+FbhgmT8QZtIm6qWu3NGA
n69O00exgPVKVjv1zhz1QoBzZn9J/MCq+N5vx/Ur6zVb8dD7+Vwu/3fvMFeuxKbx
PJ7XXUQgVuiTxxc3GNfk0nrJqLSSAbn6HAmXDY6rtpcdXt1PyaYZDoxQkKtKJtY=
=nXLP
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170224142730.GO1146%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup error - where is the log?

2017-02-24 Thread Zbigniew Łukasiak

Ok - I tried the command line version - the output is below. The same
error I see in ~/.xsession-errors. It looks to work correctly with the
symlinked tmp - but still fails somehow - maybe the archive is
corrupted.

I tried to re-make the bacup from commandline, and this reports
"qvm-backup: export error: [Errno 28] No space left on device" - even
though I have enough space on both the /home and the /var/tmp
partitions. See below for details - I mounted quite a big partition on
/var/tmp. Maybe it somehow still uses the root partition. I did not
see that error when running backup from Qubes Manager - but maybe the
problem was still there and it was corrupting the backup.




[zby@dom0 ~]$ qvm-backup-restore qubes-2017-02-22T111605 --verify-only --debug
Please enter the passphrase to verify and (if encrypted) decrypt the backup:
Checking backup content...
Working in temporary dir:/var/tmp/restore_RxbZ1b
Extracting data: 1.0 MiB to restore
Run command[u'tar', u'-ixvf', 'qubes-2017-02-22T111605', u'-C',
u'/var/tmp/restore_RxbZ1b', u'backup-header', u'backup-header.hmac',
u'qubes.xml.000', u'qubes.xml.000.hmac']
Got backup header and hmac: backup-header, backup-header.hmac
Verifying file /var/tmp/restore_RxbZ1b/backup-header
Loading hmac for file /var/tmp/restore_RxbZ1b/backup-header
File verification OK -> Sending file /var/tmp/restore_RxbZ1b/backup-header
Creating pipe in: /var/tmp/restore_RxbZ1b/restore_pipe
Getting new file:qubes.xml.000
Getting hmac:qubes.xml.000.hmac
Verifying file /var/tmp/restore_RxbZ1b/qubes.xml.000
Started sending thread
Moving to dir /var/tmp/restore_RxbZ1b
Loading hmac for file /var/tmp/restore_RxbZ1b/qubes.xml.000
File verification OK -> Sending file /var/tmp/restore_RxbZ1b/qubes.xml.000
Getting new file:
Waiting for the extraction process to finish...Extracting file
/var/tmp/restore_RxbZ1b/qubes.xml.000

Running command [u'tar', u'-xkv',
u'../../../../var/tmp/restore_RxbZ1b/qubes.xml']
Removing file /var/tmp/restore_RxbZ1b/qubes.xml.000
ERROR: unable to extract files for
/var/tmp/restore_RxbZ1b/qubes.xml.000.(u'', u'tar:
../../../../var/tmp/restore_RxbZ1b/qubes.xml: Not found in
archive\n\ntar: Exiting with failure status due to previous errors\n')
Tar command output: %s
Process ExtractWorker3-1:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/multiprocessing/process.py", line 258, in
_bootstrap
self.run()
  File "/usr/lib64/python2.7/site-packages/qubes/backup.py", line 931, in run
self.__run__()
  File "/usr/lib64/python2.7/site-packages/qubes/backup.py", line
1251, in __run__
"\n".join(self.tar2_stderr
QubesException: unable to extract files for
/var/tmp/restore_RxbZ1b/qubes.xml.000.(u'', u'tar:
../../../../var/tmp/restore_RxbZ1b/qubes.xml: Not found in
archive\n\ntar: Exiting with failure status due to previous errors\n')
Tar command output: %s
Extraction process finished with code:1
ERROR: unable to extract the qubes backup. Check extracting process errors.


===


[zby@dom0 ~]$ df
Filesystem 1K-blocks  Used Available Use% Mounted on
devtmpfs 2002988 0   2002988   0% /dev
tmpfs2014408308256   1706152  16% /dev/shm
tmpfs2014408  1316   2013092   1% /run
tmpfs2014408 0   2014408   0% /sys/fs/cgroup
/dev/dm-1   95989516  92623640 0 100% /
tmpfs201440852   2014356   1% /tmp
xenstore 2014408   240   2014168   1% /var/lib/xenstored
/dev/sda11   1889292184884   1590388  11% /boot
/dev/dm-3  288243040  67263564 206314468  25% /home
tmpfs 402884 0402884   0% /run/user/991
tmpfs 402884 8402876   1% /run/user/1000
/dev/sda7  272256456 167991052  90412476  66% /home/zby/tmp

[zby@dom0 ~]$ qvm-backup -x dom0 -x untrusted -x anon-whonix -x vault
-x personal -x work -x sys-net -x sys-firewall -x sys-whonix back -x
python-anaconda --debug
--+--+--+
   VM | type | size |
--+--+--+
myovm |AppVM |  5.0 GiB |
my-new-vm |AppVM |  9.8 GiB | <-- The VM is
running, please shut it down before proceeding with the backup!
 exch |AppVM |316.0 MiB | <-- The VM is
running, please shut it down before proceeding with the backup!
qvm-backup: export error: [Errno 28] No space left on device
--+--+--+
  Total size: |15.1 GiB |
--+--+--+
VMs not selected for backup:
anon-whonix
debian-8
debian-8-python
dom0
fedora-23
fedora-23-dvm
personal
python-anaconda
sys-firewall
sys-net
sys-whonix
untrusted
vault
whonix-gw
whonix-ws
work
ERROR: Please shutdown all VMs before proceeding.


On Thu, Feb 23, 2017 at 3:42 AM, Marek

Re: [qubes-users] Backup error - where is the log?

2017-02-23 Thread Marek Marczykowski-Górecki

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Feb 22, 2017 at 12:38:48PM -0500, Zbigniew Łukasiak wrote:
> I am getting an error message when trying to restore a VM backup:
> "unable to extract the qubes backup. Check the extracting process errors."
> 
> Where should I look for the extracting process error log?
> I don't see anything relevant in /var/log - but maybe I missed something.

If you launched the backup from Qubes Manager, check ~/.xsession-errors.

> More info:
> 
> I made a bacup using the 'System' -> 'Bacup VMs' menu entry in the
> Qubes VM Manager and then I tried to restore it with the 'System' ->
> 'Restore VMs from backup' menu entry. I tried both just veryfying the
> integrity and restoring it entirely - with the same result.
> 
> My root filesystem if full - and I noticed that the backup
> verification process tried to write to /var/tmp . This was failing -
> so I tried symlinking that directory to another filesystem and
> mounting another partition over it. This worked at the start and it
> did create a 'restore_*' directory with some files in /var/tmp -
> but then failed with the message I described above. I would like to
> look into the error message - to understand what is failing.

Out of disk space is most likely the reason. But if it isn't the case
after symlinking /var/tmp, check messages in ~/.xsession-errors. If
still nothing interesting, you can launch restoring (or verification)
from command line (qvm-backup-restore), with --debug switch.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYrqCOAAoJENuP0xzK19csQXYH/2j89aAzUg1LAemETRfxOMcy
T4oM+/ps2qlR1kgA1/LLKx6LdbW2cu5rMR9uAQhr5yHeLp15j5JXF4Ef/pFp1fXr
TrvSMl4x9z+OAUKt+6uZncyl81J7UhMzJ0ixwE58B1vxUzP76aBXz7N8BwhdCLTw
ydi0mg4Pd2iIMRV8wYCX4qxjT0M9OmYf4ClQpOcDUc8+68rEX2vwrD7vOuC0RIfu
MUjutenc3jkLEnAEr0W9cXjwCR360R4ZU5r3SaOPXXo6P4JpBwHkdYdan1uv+cPT
dGtKHMoQlgb6Gq3KPIobaMLhi+8WPv0RkThgjxodirUOHfiZ9GlVfpChtrd8Hjc=
=pEg5
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170223084254.GB13918%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup failes

2017-02-11 Thread haaber

haaber:
> > Cannot create /media/user/hexstring/qubes-backup/2017-02... : permission
> > denied.
>
> Try "sudo chown user:user /media/user/hexstring/qubes-backup".
>
> Rusty
Thank you that worked! Bernhard

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/24341d31-3953-b7d1-a67e-0e9eed76984f%40web.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup failes

2017-02-09 Thread Rusty Bird

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

haaber:
> Cannot create /media/user/hexstring/qubes-backup/2017-02... : permission
> denied.

Try "sudo chown user:user /media/user/hexstring/qubes-backup".

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJYnPnSXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfgRoP/1dJWam9ej7w+LGSN8ECzDew
t1eF65sNwrPiuZX6gZvOepkgKfqk7aUPYkeggW2MXnYPUGZKt4+ZOzFloV/29KOw
JhCgSHjmTmati3E/vvAAgBSc+LxDeozweYM0OFTql0Q5s1ha8NtmEpqlHm94G6Ok
x5XzYikRvVeHXoC3U4vmvAR974gWG9nUU+Oi4CDZrTAMQjR3uWjSqsQDH6r7vEuG
7/IWt/eFp3/196abeLqhV/zuwCzE9H6QyBMVfQOGbrJ2nKZjIStQw0v/X2vaG6nF
gTtjzv3LSj5nhP8uzrlwvIfAG85WMWofjhsILuMMVv342GmupcMEwW2U2KEwH8LB
f20H5c9iHPzzT3XTNzCRlO/be6igxHcGRsnBgH+KCZ++1B1sq4JROR5hOduu0hnD
K9fOr6Buyg1lbz3W+1wFHXIs2mBppu936Kfhs0R6A4/2hCXhZKZm72aDgpVnEoTL
MoTHHAaw6UW6iuBSirrzzvCuUhnjSPdcs7k1p9wdkwdMNmVaG5Xl+Qb6EB5XfrV0
kO2/F56OTZmsE8H3n0oF/sNwVAbZmN9g4eOujdDm0a4rHMx/fwQFGH9CrHsdKCK7
T5FhWHIXk0JJ7C98s9MNb+BWVIlkZ19RXPnKa5ishnuIkcEWG/+UE21UccUxh8mh
yff9xd+OMCZ0mx9FaK9U
=rDDj
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170209232258.GA2634%40mutt.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] backup failes

2017-02-09 Thread haaber

Hello,

I tried the built-in backup procedure in qubes3.2 -- it fails (from
qubes VM manager). The procedure I follow: I select only shutdown qubes,
I select sys-usb as appvm (in which the ext. harddisc is mouted on
/media/user/hexstring/ and in which I manually created a qubes-backup
folder that I select. I enter the pwd, get the summary, say next again,
and then:

Error: failed to write the backup:

Cannot create /media/user/hexstring/qubes-backup/2017-02... : permission
denied.

And that's it. Do you have some hint what my error may be? I read about
te size issue of the qubes. I have more than 100G in total. I it that
maybe? Can I only backup the old way (create a sparse file, loopback it,
cryptsetup it, put ext2 on it, mount it, copy all private.img files) ?

Thank you! Bernhard

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/880a127f-8251-3946-1bf6-f8a19239c1bc%40web.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] "Backup VMs" does not backup salt configuration

2017-02-05 Thread john.david.r.smith

On 05/02/17 23:59, john.david.r.smith wrote:

On 05/02/17 00:06, Oleg Artemiev wrote:

Hi.

On Wed, Feb 1, 2017 at 11:56 PM, john.david.r.smith
wrote:

On 01/02/17 21:30, qu...@posteo.de wrote:

I have now nearly a complete salt configuration for all my templates so I
do not need to backup them anymore and save a lot of space by this.

So I have ran a backup including dom0 and realized that the salt
configuration ("/srv/salt") does not seem to be included because it is much
bigger than the MB listed for dom0.

Is there a way to back it up right now with this method or do I manually
have to copy everything outside of dom0?

Thx in advance

i put my files in ~/salt and symlinked them to /srv/salt
then backups should work

Could you point to source for more information on your work?

Backups work slow (disk/network bottlenecks) & I'm also interested to
backup less.

i started to extend the salt documentation and just added an pull-request.
you can find my repo of the doc here:

https://github.com/john-david-r-smith/qubes-doc/blob/salt-doc/configuration/salt.md

here the correct link (i failed to push on my branch...):
https://github.com/john-david-r-smith/qubes-doc/blob/master/configuration/salt.md

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/d90a0278-4868-264f-8abf-2f8232788037%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] "Backup VMs" does not backup salt configuration

2017-02-05 Thread john.david.r.smith

On 05/02/17 00:06, Oleg Artemiev wrote:

Hi.

On Wed, Feb 1, 2017 at 11:56 PM, john.david.r.smith
wrote:

On 01/02/17 21:30, qu...@posteo.de wrote:

I have now nearly a complete salt configuration for all my templates so I
do not need to backup them anymore and save a lot of space by this.

So I have ran a backup including dom0 and realized that the salt
configuration ("/srv/salt") does not seem to be included because it is much
bigger than the MB listed for dom0.

Is there a way to back it up right now with this method or do I manually
have to copy everything outside of dom0?

Thx in advance

i put my files in ~/salt and symlinked them to /srv/salt
then backups should work

Could you point to source for more information on your work?

Backups work slow (disk/network bottlenecks) & I'm also interested to
backup less.

i started to extend the salt documentation and just added an pull-request.
you can find my repo of the doc here:

https://github.com/john-david-r-smith/qubes-doc/blob/salt-doc/configuration/salt.md

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/2505d2c9-ff11-08e0-b815-bf768464b65a%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] "Backup VMs" does not backup salt configuration

2017-02-05 Thread qubes


Hey,

On 05.02.2017 00:06, Oleg Artemiev wrote:

Hi.

On Wed, Feb 1, 2017 at 11:56 PM, john.david.r.smith
 wrote:

On 01/02/17 21:30, qu...@posteo.de wrote:
I have now nearly a complete salt configuration for all my templates 
so I

do not need to backup them anymore and save a lot of space by this.


Could you point to source for more information on your work?


I have not posted my work anywhere but I learned most things from this 
repo https://github.com/Nekroze/qubes-salt

 and of course the salt documentation and hints from John

Regards

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d3860054a52b9e9541b8aa80793ef99f%40posteo.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] "Backup VMs" does not backup salt configuration

2017-02-04 Thread Oleg Artemiev

Hi.

On Wed, Feb 1, 2017 at 11:56 PM, john.david.r.smith
 wrote:
> On 01/02/17 21:30, qu...@posteo.de wrote:
>> I have now nearly a complete salt configuration for all my templates so I
>> do not need to backup them anymore and save a lot of space by this.
>>
>> So I have ran a backup including dom0 and realized that the salt
>> configuration ("/srv/salt") does not seem to be included because it is much
>> bigger than the MB listed for dom0.
>>
>> Is there a way to back it up right now with this method or do I manually
>> have to copy everything outside of dom0?
>>
>> Thx in advance
>>
>
> i put my files in ~/salt and symlinked them to /srv/salt
> then backups should work

Could you point to source for more information on your work?

Backups work slow (disk/network bottlenecks) & I'm also interested to
backup less.

-- 
Bye.Olli.
gpg --search-keys grey_olli , use key w/ fingerprint below:
Key fingerprint = 9901 6808 768C 8B89 544C  9BE0 49F9 5A46 2B98 147E
Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABunX6Of_4KrpHRFSvcpLLd1sWPg6BKqjJiBsBuQvr8F1d2VBQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] "Backup VMs" does not backup salt configuration

2017-02-01 Thread john.david.r.smith


On 01/02/17 21:30, qu...@posteo.de wrote:

Hi,

I have now nearly a complete salt configuration for all my templates so I do 
not need to backup them anymore and save a lot of space by this.

So I have ran a backup including dom0 and realized that the salt configuration 
("/srv/salt") does not seem to be included because it is much bigger than the 
MB listed for dom0.

Is there a way to back it up right now with this method or do I manually have 
to copy everything outside of dom0?

Thx in advance



i put my files in ~/salt and symlinked them to /srv/salt
then backups should work

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ba5ec9f2-6b8c-7bf0-570d-7c3e6aac5c84%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] "Backup VMs" does not backup salt configuration

2017-02-01 Thread qubes


Hi,

I have now nearly a complete salt configuration for all my templates so 
I do not need to backup them anymore and save a lot of space by this.


So I have ran a backup including dom0 and realized that the salt 
configuration ("/srv/salt") does not seem to be included because it is 
much bigger than the MB listed for dom0.


Is there a way to back it up right now with this method or do I manually 
have to copy everything outside of dom0?


Thx in advance

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8c65360dab475f3f0bc91ba72d62effc%40posteo.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup

2016-09-29 Thread Andrew David Wong

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-09-28 00:32, Gabriel wrote:
> On 2016-09-27 06:59, 'Gabriel' via qubes-users wrote:
>> 2. I tried running qvm-backup from the command line, which ran fine, no 
>> permission problems on the same HDD. However, the template VMs are not 
>> included by default and I saw no command-line option to automatically 
>> achieve this. Am I missing something here?
>>
> 
>> The RPM-managed TemplateVMs should normally not be backed up. Instead, you 
>> should clone them (if you can spare the drive space), make your 
>> customizations, then back up the clones.
> Does this imply the AppVMs should be based upon the cloned VMs?
> 

Correct.

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJX7RfIAAoJENtN07w5UDAwfJoQAMOEl75O7pfUH1bddOcBrAmD
+q+ocQta8pEjI3j3atG1pxcuTUDFrG32BkrZ7OrbIBEOw3PeapNYh0ht1peamdx7
UJJ9uk5LJ1RE2yiKSAB80mRntgJUEI/MimblEPkG/wPFFlJi1drp0gAA42y0oBg3
ioYmsEoX3buCxN9nj2iOdLsqe+WVlMJJwK1tmBIoryEfvuKmiGlMfuI/Y0zJFSPM
TWWhHtPwu83lhZRQW/bk1PU0nP3m8iFr9ia3orYZaGODnHs6ukCQJfFmlNRsCg/5
BFuuIYdm3lUBdyXobzYHtJea5N/XACWl+QHW58a0YQij7ZfqFAvlynP5SKujrTuU
BMbxHJ8DCfdOjv8lazgt4a0fac82whXXr/qSGMePz/ROzhiQy1jFtAB4/vXe4OKM
SrHh97jKdROp9TcH7SLSIg+inSOqMUk3Ax8IVvJ8V1rij+VWz67FJdf2g/FmgS2b
LL6ZTTeHE+EAI1ToT2QSmp3hbWmjNSRSuzFT/bj0GpqwK/IJpRLLOwirOGoU8DRl
Mq6QLmhU0mV5dgVs92MH3Ekyk06qUh9v5RbhkTJJTg0yQnloAa6JTcsNnB2m5HKq
vFAUjMOmJ3Juz+BmSUwhm+chmVqoC0iHVkspTpoMjutELCmhi9IVN1b79P7eVFNG
AA33k2NAdCAm8Zlc4Y/Z
=Pge6
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1c043b27-1201-6917-36d2-2c2388658293%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup

2016-09-28 Thread 'Gabriel' via qubes-users

On 2016-09-27 06:59, 'Gabriel' via qubes-users wrote:
> Hi fellows,
>
> I started using qubes a while ago and I have a question concerning backups.
> What I want is a complete backup to a dedicated external USB HDD. I 
> understand to achieve this all the VMs must be shut down.
> Therefore when I plugged in the HDD I mounted it in dom0 under /mnt.
>

>This is fine as long as you trust the USB device you're attaching to dom0. If 
>you don't, consider using a USB qube instead:

>https://www.qubes-os.org/doc/usb/#creating-and-using-a-usb-qube
The USB device is trsted but I'll consider the usb-cube too.


> Questions:
> 1. When I ran Qubes VM Manager -> Backup VMs, I received an error message 
> stating no place on device and a zero byte backup file. Permissions are OK, 
> there's more than enough space on the HDD.
> Any reasons why the backup did not succeed?
>

>Are you sure you selected the correct device in the menu?
There was only one option 

> 2. I tried running qvm-backup from the command line, which ran fine, no 
> permission problems on the same HDD. However, the template VMs are not 
> included by default and I saw no command-line option to automatically achieve 
> this. Am I missing something here?
>

>The RPM-managed TemplateVMs should normally not be backed up. Instead, you 
>should clone them (if you can spare the drive space), make your 
>customizations, then back up the clones.
Does this imply the AppVMs should be based upon the cloned VMs?


> 3. I know I can manually list all the VMs on the command line to be backed 
> up, but I find that a bit awkward, so I tried this:
> qvm-ls --raw-list | xargs qvm-backup /mnt/test/
>
> but this threw a Python exception...
>
> For now I resorted to typing all the VMs by hand ... not elegant.
>
> Any help is appreciated.
>

Try this:

$ qvm-backup /mnt/test/ `qvm-ls --raw-list`
This one works nice, thank you.

Gabe

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7jVsr2iHJEOfEeyN1cR_geYvDZnXIWWUa4iu_iCYAGBrQnpPD1p03FxuJdeTqK1qbIB8SPZZihvglfzbMD4iC0d97cn2RTKdO2lB2nuweio%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup

2016-09-27 Thread Andrew David Wong

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-09-27 06:59, 'Gabriel' via qubes-users wrote:
> Hi fellows,
> 
> I started using qubes a while ago and I have a question concerning backups.
> What I want is a complete backup to a dedicated external USB HDD. I 
> understand to achieve this all the VMs must be shut down.
> Therefore when I plugged in the HDD I mounted it in dom0 under /mnt.
> 

This is fine as long as you trust the USB device you're attaching to dom0. If 
you don't, consider using a USB qube instead:

https://www.qubes-os.org/doc/usb/#creating-and-using-a-usb-qube

> Questions:
> 1. When I ran Qubes VM Manager -> Backup VMs, I received an error message 
> stating no place on device and a zero byte backup file. Permissions are OK, 
> there's more than enough space on the HDD.
> Any reasons why the backup did not succeed?
> 

Are you sure you selected the correct device in the menu?

> 2. I tried running qvm-backup from the command line, which ran fine, no 
> permission problems on the same HDD. However, the template VMs are not 
> included by default and I saw no command-line option to automatically achieve 
> this. Am I missing something here?
> 

The RPM-managed TemplateVMs should normally not be backed up. Instead, you 
should clone them (if you can spare the drive space), make your customizations, 
then back up the clones.

> 3. I know I can manually list all the VMs on the command line to be backed 
> up, but I find that a bit awkward, so I tried this:
> qvm-ls --raw-list | xargs qvm-backup /mnt/test/
> 
> but this threw a Python exception...
> 
> For now I resorted to typing all the VMs by hand ... not elegant.
> 
> Any help is appreciated.
> 

Try this:

  $ qvm-backup /mnt/test/ `qvm-ls --raw-list`

You can also prepare a list of VMs (one VM name per line) as a file, then:

  $ qvm-backup /mnt/test/ `cat vm_list.txt`

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJX6rLjAAoJENtN07w5UDAwuJQQAMu+Wfr56Bmf6bmJVCrZWY76
ZosTo+0ouB7jBYcoplACyirVmXjhFK3G9AFKRnpNZ3qo7m9w3rWD6cgbYwv88yfW
nTJZBV88xqQqLGjqz3+OCi84/sfpOgIC8tXhzZndKcGb+5yd0FxRgZhZg4shdJ4d
DoBX2hAfwzaUG9FCH7spaIFE5XPeOXNlK+ft5kuhbstWxGsFz7plf1ibrRii+Z2U
DNamPVhAD6x4/cIzakb57SJ4BWcDoCuyeeG0ICpHyTjEMBq3GH0pvt4bVsSIWUC8
3LrUYAkuKrtxeSBHuJ0eAMilpkz9rld8tl58FUiMW1ZkanSYYB/GV8ENhAruFvVL
bvlgJ0vsOBg1FRXGC8LUUsXiw2owUP4z7Dgtl3Q5eZ+Zb1K/OAdbnmrkXbu/PpiR
E50qQig/Ugxlg9XDdWCgANfFRfhdi2btA+qfP7aSJt+0Kf60GxmQtUGbHm+Q0ECP
L03ZEFG33K/3xu26CFXjWQRwlFGMAAUF5BEiFuLDJ96rhwU5blHjV/lZ1e1rEyv1
uRjdJ06slyv78uLanqIXyMqH1nXBlu/RyayrqTJW1Jdo0GX3iSoF7SR1A8zPbf3r
3d/PmRfY2/1/okIcFYc0tkqq9fTvi0M+ixVIdPmYzoVuzsiP/y5tBM+7CT5YxY+q
0KnOMeWlDzFguSEdha+e
=KRMx
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d7357dd5-7283-2368-17c0-2f88113418dc%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup

2016-09-27 Thread Jeremy Rand

'Gabriel' via qubes-users:
> Hi fellows,
> 
> I started using qubes a while ago and I have a question concerning backups.
> What I want is a complete backup to a dedicated external USB HDD. I 
> understand to achieve this all the VMs must be shut down.
> Therefore when I plugged in the HDD I mounted it in dom0 under /mnt.

You can backup a subset of VM's from the GUI.  I typically backup every
VM except the USB VM (with the external HDD attached to the USB VM and
mounted in a DispVM), under the assumption that if I'm ever restoring to
a fresh Qubes install, there will already be a USB VM there, so backing
up the USB VM isn't really needed.

Cheers,
-Jeremy

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/58032d10-22a7-7c1b-8ee1-bd95c4ba563a%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[qubes-users] backup

2016-09-27 Thread 'Gabriel' via qubes-users

Hi fellows,

I started using qubes a while ago and I have a question concerning backups.
What I want is a complete backup to a dedicated external USB HDD. I understand
to achieve this all the VMs must be shut down.
Therefore when I plugged in the HDD I mounted it in dom0 under /mnt.

Questions:
1. When I ran Qubes VM Manager -> Backup VMs, I received an error message
stating no place on device and a zero byte backup file. Permissions are OK,
there's more than enough space on the HDD.
Any reasons why the backup did not succeed?

2. I tried running qvm-backup from the command line, which ran fine, no
permission problems on the same HDD. However, the template VMs are not included
by default and I saw no command-line option to automatically achieve this. Am I
missing something here?

3. I know I can manually list all the VMs on the command line to be backed up,
but I find that a bit awkward, so I tried this:
qvm-ls --raw-list | xargs qvm-backup /mnt/test/

but this threw a Python exception...

For now I resorted to typing all the VMs by hand ... not elegant.

Any help is appreciated.

Best,
Gabe

Sent with [ProtonMail](https://protonmail.com) Secure Email.

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/zCWKQXq5-iWoiqonoLuMnWRCPGbQlTqt7ynO8NCwUR_yrxmvRnC9l5fZUSX_zQsl9tUkxFJgZcJpnCOmLpecKQHH0Lhh5mpGda4bKHFwJmA%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup Encryption Options

2016-08-16 Thread Andrew David Wong

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-16 10:07, entr0py wrote:
> According to:
> 
> https://www.qubes-os.org/doc/backup-restore/ 
> https://groups.google.com/forum/#!searchin/qubes-users/ 
> backup$20encryption|sort:relevance/qubes-users/sS4A3vJdCQ8/w9-jIj5VW9oJ
> 
> Qubes backup system has a "weak key derivation scheme".
> 
> Is a reasonable workaround to just put the backups (with or without Qubes 
> encryption) on a LUKS device?
> 

Yes.

You can also read more about the key derivation issue here:

https://github.com/QubesOS/qubes-issues/issues/971

> And a general cryptsetup question: Is there any security benefit to 
> encrypting an entire drive versus encrypting individual partitions (ie 
> /dev/sda vs /dev/sda1)?
> 

Hm. Good question. One case where encrypting the entire drive would be better
is if the OS might potentially write metadata, temp files, etc. to unencrypted
partitions. If we're only considering an encrypted volume for storing data at
rest (e.g., encrypting an entire external hard drive versus just a partition
on that external hard drive), then I'd wager there's not much of a difference.
It would be best to ask the cryptsetup devs, though (or just anyone more
knowledgeable than me).

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXs0tHAAoJENtN07w5UDAw/HMQAKayEjqVm8iVj6kQN7oMy9G5
R2mCXRXRy1YOB13lbiLhAt5P0xokp8TWVUedVV5Ysx/64mW2tTwCzwfdQvBSzZUn
JmK7PbhGOgkK+Az5QZhVC9iYk+QtuamVesjvcorc+V2+321guKOj3nC7rNA32KTV
qKrN+ows67P+ASfHP7K3Gf+KMVOVIFxqUP1olbOomEolVGXgIImBFK896kGyowN4
VPSH2AJhp1X1i5EhBsGWvBVvqZnH1S+FvT1f948RBJzpEeQBWfSlTdv+U79l6nsB
X1q1uhm1wWQmung+UMtqVnRlJq2Qo/QSUZt7TOYxGWI1PjX7+2BoV4DqB/2dYW5r
Yy8a7MEXZcKWFTAAu2qksGfglFwy2W1mMb6/0Pcmi/QQvbzmgcGKV9k2IaNfwXpA
J6GSrzEpCoaR5rYUjuTm7dDT41XhPZuHM0dAgdg8MPvppjIDLh6cjZF+y0fogMIm
PshSa4hgRGouxwAb1wfh8C5Y1J/tixm1bU9MNgQCTD6SXL/bP1wKAHWZLWV7cORM
66dg4ZQk83JaY0Wcc4ByoVWsxRVXfIi5ALlcDdGI/2VAg+MCTTxsCfXDcFO6KyPh
so6DotmuMQr+6NlYE0kvRcHeoVb6xc+vUIX9eSZMXoSlyZgMW1CuXZ4pICQHsr68
E2Km5Pp6SiuYbsVgP6G/
=Tmo2
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8eb258e9-d6fe-5ccb-71a0-67b7d02be0b4%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

74 matches

Mail list logo