Opened 12 years ago
Closed 12 years ago
#2409 closed enhancement (duplicate)
Backup multiple XOs to one USB drive
| Reported by: | sridhar | Owned by: | sascha_silbe |
|---|---|---|---|
| Priority: | Unspecified by Maintainer | Milestone: | Unspecified |
| Component: | Backup | Version: | Unspecified |
| Severity: | Unspecified | Keywords: | |
| Cc: | sridhar | Distribution/OS: | OLPC |
| Bug Status: | Unconfirmed |
Description
Having one USB drive per XO for the purposes of backing up can be expensive and also difficult to manage.
It would be useful for a teacher to have one high-capacity USB drive, which can be used to back up the XOs for the whole class. This requires two portions:
- Backup will have to save each backup in a sensible way so that they don't clobber each other
- Restore will have to provide a friendly UI to select the correct backup file to restore
Change History (5)
comment:1 Changed 12 years ago by sridhar
- Cc sridhar added
comment:2 Changed 12 years ago by sascha_silbe
- Owner changed from silbe to sascha_silbe
- Status changed from new to assigned
comment:3 in reply to: ↑ description Changed 12 years ago by sascha_silbe
comment:4 follow-up: ↓ 5 Changed 12 years ago by JerryV
This is working as designed after applying the fix from:
comment:5 in reply to: ↑ 4 Changed 12 years ago by sascha_silbe
- Resolution set to duplicate
- Status changed from assigned to closed
Note: See
TracTickets for help on using
tickets.
Replying to sridhar:
This was the case since the first release. The file name includes the configured name of the learner, the laptop serial number (resp. the hash of the Sugar public key in case of non-XO hardware), the date of the backup run and if necessary a random string (if several backups of the same installation are taken on the same day).
You could enter the name of the learner in the search bar of the Journal. That should show either just a single bundle or at least just a few (in case there are multiple kids that use the same name inside Sugar).
Listing just the matching bundle(s) in Restore is a bit trickier to implement. We'd have to bypass the Journal (Object Chooser in this case) like we do in Backup; only this time we need to scan all the storage devices for matching bundles instead of just listing them. Also we'd need some way to let the user select a bundle that does not match the naming conventions (e.g. for restoring to a replacement machine). Maybe show all bundles, but sort the matching ones to the top of the list. We'd also have to deal with naming variations due to i18n (the file name gets translated)...